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Bevezetés 


Ez a bevezetés áttekintést ad a Ct4t programozási nyelv fő fogalmairól, tulajdonságairól és 
standard (szabvány) könyvtáráról, valamint bemutatja a könyv szerkezetét és elmagyarázza 
azt a megközelítést, amelyet a nyelv lehetőségeinek és azok használatának leírásánál 
alkalmaztunk. Ezenkívül a bevezető fejezetek némi háttérinformációt is adnak a C---ról, 
annak felépítéséről és felhasználásáról. 


Fejezetek 


1. Megjegyzések az olvasóhoz 
2. Kirándulás a C4t-4-ban 
3. Kirándulás a standard könyvtárban 





Megjegyzések az olvasóhoz 


, Szólt a Rozmár: 
Van ám elég, miről mesélni jó: ..." 
(. Carroll — ford. Tótfalusi István) 


A könyv szerkezete s Hogyan tanuljuk a C---t? s A C4- jellemzői 9" Hatékonyság és szer- 
kezet e Filozófiai megjegyzés s Történeti megjegyzés e Mire használjuk a C---t? s C és 
Ct4 e Javaslatok C programozóknak s Gondolatok a C-t programozásról s Tanácsok e 
Hivatkozások 


1.1. A könyv szerkezete 


A könyv hat részből áll: 


Bevezetés: Az 1-3. fejezetek áttekintik a C4-4 nyelvet, az általa támogatott fő progra- 
mozási stílusokat, és a C44 standard könyvtárát. 
Első rész: A 4-9. fejezetek oktató jellegű bevezetést adnak a C-t beépített típusai- 


ról és az alapszolgáltatásokról, melyekkel ezekből programot építhetünk. 
Második rész: A 10-15. fejezetek bevezetést adnak az objektumorientált és az 
általánosított programozásba a C--- használatával. 


4 Bevezetés 


Harmadik rész: A 16-22. fejezetek bemutatják a Ct- standard könyvtárát. 
Negyedik rész: A 23-25. fejezetek tervezési és szoftverfejlesztési kérdéseket tárgyalnak. 
Függelékek: Az A-E függelékek a nyelv technikai részleteit tartalmazzák. 


Az 1. fejezet áttekintést ad a könyvről, néhány ötletet ad, hogyan használjuk, valamint 
háttérinformációkat szolgáltat a Ct--ról és annak használatáról. Az olvasó bátran átfuthat 
rajta, elolvashatja, ami érdekesnek látszik, és visszatérhet ide, miután a könyv más részeit 
elolvasta. 


A 2. és 3. fejezet áttekinti a C-t programozási nyelv és a standard könyvtár fő fogalmait és 
nyelvi alaptulajdonságait, megmutatva, mit lehet kifejezni a teljes C-t nyelvvel. Ha semmi 
mást nem tesznek, e fejezetek meg kell győzzék az olvasót, hogy a C-t nem (csupán) C, és 
hogy a Csi hosszú utat tett meg e könyv első és második kiadása óta. A 2. fejezet magas 
szinten ismertet meg a C-t--szal. A figyelmet azokra a nyelvi tulajdonságokra irányítja, me- 
lyek támogatják az elvont adatábrázolást, illetve az objektumorientált és az általánosított 
programozást. A 3. fejezet a standard könyvtár alapelveibe és fő szolgáltatásaiba vezet be, 
ami lehetővé teszi, hogy a szerző a standard könyvtár szolgáltatásait használhassa a követ- 
kező fejezetekben, valamint az olvasónak is lehetőséget ad, hogy könyvtári szolgáltatáso- 
kat használjon a gyakorlatokhoz és ne kelljen közvetlenül a beépített, alacsony szintű tulaj- 
donságokra hagyatkoznia. 


A bevezető fejezetek egy, a könyv folyamán általánosan használt eljárás példáját adják: ah- 
hoz, hogy egy módszert vagy tulajdonságot még közvetlenebb és valószerűbb módon vizs- 
gálhassunk, alkalmanként először röviden bemutatunk egy fogalmat, majd később beha- 
tóbban tárgyaljuk azt. Ez a megközelítés lehetővé teszi, hogy konkrét példákat mutassunk 
be, mielőtt egy témát általánosabban tárgyalnánk. A könyv felépítése így tükrözi azt a meg- 
figyelést, hogy rendszerint úgy tanulunk a legjobban, ha a konkréttól haladunk az elvont 
felé — még ott is, ahol visszatekintve az elvont egyszerűnek és magától értetődőnek látszik. 


Az I. rész a Ct4-nak azt a részhalmazát írja le, mely a C-ben vagy a Pascalban követett ha- 
gyományos programozási stílusokat támogatja. Tárgyalja a Ctt programokban szereplő 
alapvető típusokat, kifejezéseket, vezérlési szerkezeteket. A modularitást, mint a névterek, 
forrásfájlok és a kivételkezelés által támogatott tulajdonságot, szintén tárgyalja. Feltételez- 
zük, hogy az olvasónak már ismerősek az I. fejezetben használt alapvető programozási fo- 
galmak, így például bemutatjuk a C-- lehetőségeit a rekurzió és iteráció kifejezésére, de 
nem sokáig magyarázzuk, milyen hasznosak ezek. 


A II. rész a Cr új típusok létrehozását és használatát segítő szolgáltatásait írja le. Itt (10. és 
12. fejezet) mutatjuk be a konkrét és absztrakt osztályokat (felületeke), az operátor-túlter- 
heléssel (11. fejeze), a többalakúsággal (polimorfizmussaD) és az osztályhierarchiák hasz- 
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nálatával (12. és 15. fejezet) együtt. A 13. fejezet a sablonokat (template) mutatja be, vagyis 
a C-t lehetőségeit a típus- és függvénycsaládok létrehozására, valamint szemlélteti a táro- 
lók előállítására (pl. listák), valamint az általánosított (generikus) programozás támogatásá- 
ra használt alapvető eljárásokat. A 14. fejezet a kivételkezelést, a hibakezelési módszereket 
tárgyalja és a hibatűrés biztosításához ad irányelveket. Feltételezzük, hogy az olvasó az ob- 
jektumorientált és az általánosított programozást nem ismeri jól, illetve hasznát látná egy 
magyarázatnak, hogyan támogatja a C-t a fő elvonatkoztatási (absztrakciós) eljárásokat. 
Így tehát nemcsak bemutatjuk az elvonatkoztatási módszereket támogató nyelvi tulajdon- 
ságokat, hanem magukat az eljárásokat is elmagyarázzuk. A IV. rész ebben az irányban ha- 
lad tovább. 


A III. rész a Ct4t standard könyvtárát mutatja be. Célja: megértetni, hogyan használjuk 
a könyvtárat; általános tervezési és programozási módszereket szemléltetni és megmutatni, 
hogyan bővítsük a könyvtárat. A könyvtár gondoskodik tárolókról (konténerek — list, 
vector, map, 18. és 19. fejezet), szabványos algoritmusokról (sort, find, merge, 18. és 19. 
fejezet), karakterlánc-típusokról és -műveletekről (20. fejezet), a bemenet és kimenet keze- 
léséről (input/output, 21. fejeze), valamint a számokkal végzett műveletek ( numerikus 


számítás") támogatásáról (22. fejeze). 


A IV. rész olyan kérdéseket vizsgál, melyek akkor merülnek fel, amikor nagy szoftverrend- 
szerek tervezésénél és kivitelezésénél a C----t használjuk. A 23. fejezet tervezési és vezeté- 
si kérdésekkel foglalkozik. A 24. fejezet a Ct4t programozási nyelv és a tervezési kérdések 
kapcsolatát vizsgálja, míg a 25. fejezet az osztályok használatát mutatja be a tervezésben. 


Az , A" függelék a C-s-- nyelvtana, néhány jegyzettel. A ,B" függelék a C és a Cs közti és 
a szabványos C4- (más néven ISO C-t, ANSI C-4-) illetve az azt megelőző C-4---változatok 
közti rokonságot vizsgálja. A , C" függelék néhány nyelvtechnikai példát mutat be, A ,D" 
függelék pedig a kulturális eltérések kezelését támogató standard könyvtárbeli elemeket 
mutatja be. Az , E" függelék a standard könyvtár kivételkezelésel kapcsolatos garanciáit és 


követelményeit tárgyalja. 


1.1.1. Példák és hivatkozások 


Könyvünk az algoritmusok írása helyett a program felépítésére fekteti a hangsúlyt. Követ- 
kezésképpen elkerüli a ravasz vagy nehezebben érthető algoritmusokat. Egy egyszerű 
eljárás alkalmasabb az egyes fogalmak vagy a programszerkezet egy szempontjának szem- 
léltetésére. Például Shell rendezést használ, ahol a valódi kódban jobb lenne gyorsrende- 
zést (guicksort) használni. Gyakran jó gyakorlat lehet a kód újraírása egy alkalmasabb algo- 
ritmussal. A valódi kódban általában jobb egy könyvtári függvény hívása, mint a könyvben 
használt, a nyelvi tulajdonságok szemléltetésére használt kód. 


6 Bevezetés 


A tankönyvi példák szükségszerűen egyoldalú képet adnak a programfejlesztésről. Tisztáz- 
va és egyszetűsítve a példákat a felmerült bonyolultságok eltűnnek. Nincs, ami helyettesí- 
tené a valódi programok írását, ha benyomást akarunk kapni, igazából milyen is a progra- 
mozás és egy programozási nyelv. Ez a könyv a nyelvi tulajdonságokra és az alapvető 
eljárásokra összpontosít, anelyekből minden program összetevődik, valamint az összeépí- 
tés szabályaira. 


A példák megválasztása tükrözi fordítóprogramokkal, alapkönyvtárakkal, szimulációkkal 


jellemezhető hátteremet. A példák egyszerűsített változatai a valódi kódban találhatóknak. 
Egyszerűsítésre van szükség, hogy a programozási nyelv és a tervezés lényeges szempont- 
jai el ne vesszenek a részletekben. Nincs , ügyes" példa, amelynek nincs megfelelője a va- 


lódi kódban. Ahol csak lehetséges, a , C" függelékben lévő nyelvtechnikai példákat olyan 
alakra hoztam, ahol a változók xx és )y, a típusok A és B, a függvények /0 és g0 nevűek. 


A kódpéldákban az azonosítókhoz változó szélességű betűket használunk. Például: 


iincludeziostream: 


int mainO 


; std::cout Sz "Helló, világ Nm"; 

j 
Első látásra ez , természetellenesnek" tűnhet a programozók számára, akik hozzászoktak, 
hogy a kód állandó szélességű betűkkel jelenik meg. A változó szélességű betűket általá- 
ban jobbnak tartják szöveghez, mint az állandó szélességűt. A változó szélességű betűk 
használata azt is lehetővé teszi, hogy a kódban kevesebb legyen a logikátlan sortörés. Ezen- 
kívül saját kísérleteim azt mutatják, hogy a legtöbb ember kis idő elteltével könnyebben ol- 
vashatónak tartja az új stílust. 


Ahol lehetséges, a C-t nyelv és könyvtár tulajdonságait a kézikönyvek száraz bemutatási 
módja helyett a felhasználási környezetben mutatjuk be. A bemutatott nyelvi tulajdonságok 
és leírásuk részletessége a szerző nézetét tükrözik, aki a legfontosabb kérdésnek a követke- 
zőt tartja: mi szükséges a C4t- hatékony használatához? A nyelv teljes leírása — a könnyebb 
megközelítés céljából jegyzetekkel ellátva — a 7he Annotated C3-4 Language Standard című 
kézikönyvben található, mely Andrew Koenig és a szerző műve. Logikusan kellene hogy le- 
gyen egy másik kézikönyv is, a 1he Annotated C4-4 Standard Library. Mivel azonban mind 
az idő, mind írási kapacitásom véges, nem tudom megígérni, hogy elkészül. 


A könyv egyes részeire való hivatkozások §2.3.4 (2. fejezet, 3.szakasz, 4. bekezdés), §B.5.6 
( B" függelék, 5.6. bekezdés és §6.[10K(6. fejezet, 10. gyakorla) alakban jelennek meg. 
A dőlt betűket kiemelésre használjuk (pl. ,egy karakterlánc-literál nem fogadható el"), fon- 
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tos fogalmak első megjelenésénél (pl. többalakúság), a Ct-4 nyelv egyes szimbólumainál 
(pl. for utasítás), az azonosítóknál és kulcsszavaknál, illetve a kódpéldákban lévő megjegy- 
zéseknél. 


1.1.2. Gyakorlatok 


Az egyes fejezetek végén gyakorlatok találhatók. A gyakorlatok főleg az , írj egy programot" 
típusba sorolhatók. Mindig annyi kódot írjunk, ami elég ahhoz, hogy a megoldás fordítha- 
tó és korlátozott körülmények között futtatható legyen. A gyakorlatok nehézségben jelen- 
tősen eltérőek, ezért becsült nehézségi fokukat megjelöltük. A nehézség hatványozottan 
nő, tehát ha egy C1) gyakorlat 10 percet igényel, egy (2) gyakorlat egy órába, míg egy (3) 
egy napba kerülhet. Egy program megírása és ellenőrzése inkább függ az ember tapasztalt- 
ságától, mint magától a gyakorlattól. 


1.1.3. Megjegyzés az egyes C-t -H-változatokhoz 


A könyvben használt nyelv , tiszta Cr", ahogyan a Cr szabványban leírták [C----, 19981]. 
Ezért a példáknak futniuk kell minden C---változaton. A könyvben szereplő nagyobb 
programrészleteket több környezetben is kipróbáltuk, azok a példák azonban, melyek 
a C44-ba csak nemrégiben beépített tulajdonságokat használnak fel, nem mindenhol fordít- 
hatók le. (Azt nem érdemes megemlíteni, mely változatokon mely példákat nem sikerült le- 
fordítani. Az ilyen információk hamar elavulnak, mert a megvalósításon igyekvő programo- 
zók keményen dolgoznak azon, hogy nyelvi változataik helyesen fogadjanak el minden 
C--4 tulajdonságot.) A , B" függelékben javaslatok találhatók, hogyan birkózzunk meg a ré- 
gi Cr fordítókkal és a C fordítókra írott kóddal. 


1.2. Hogyan tanuljuk a C-----t? 


A C34 tanulásakor a legfontosabb, hogy a fogalmakra összpontosítsunk és ne vesszünk el 
a részletekben. A programozási nyelvek tanulásának célja az, hogy jobb programozóvá vál- 
junk; vagyis hatékonyabbak legyünk új rendszerek tervezésénél, megvalósításánál és régi 
rendszerek karbantartásánál. Ehhez sokkal fontosabb a programozási és tervezési módsze- 
rek felfedezése, mint a részletek megértése; az utóbbi idővel és gyakorlattal megszerezhető. 


8 Bevezetés 


A C4-4 sokféle programozási stílust támogat. Ezek mind az erős statikus típusellenőrzésen 
alapulnak és legtöbbjük a magas elvonatkoztatási szint elérésére és a programozó elképze- 
léseinek közvetlen leképezésére irányul. Minden stílus el tudja érni a célját, miközben ha- 
tékony marad futási idő és helyfoglalás tekintetében. Egy más nyelvet (mondjuk C, Fortran, 
Smalltalk, Lisp, ML, Ada, Eiffel, Pascal vagy Modula-2) használó programozó észre kell hogy 
vegye, hogy a Csi előnyeinek kiaknázásához időt kell szánnia a Ct-t programozási stílu- 
sok és módszerek megtanulására és megemésztésére. Ugyanez érvényes azon programo- 
zókra is, akik a C4- egy régebbi, kevésbé kifejezőképes változatát használták. 


Ha gondolkodás nélkül alkalmazzuk az egyik nyelvben hatékony eljárást egy másik nyelv- 
ben, rendszerint nehézkes, gyenge teljesítményű és nehezen módosítható kódot kapunk. 
Az ilyen kód írása is csalódást okoz, mivel minden sor kód és minden fordítási hiba arra em- 
lékeztet, hogy a nyelv, amit használunk, más, mint ,a régi nyelv". Írhatunk Fortran, C, 
kellemes, sem gazdaságos. Minden nyelv gazdag forrása lehet az ötleteknek, hogyan írjunk 
C4-4 programot. Az ötleteket azonban a C-- általános szerkezetéhez és típusrendszeréhez 


kell igazítani, hogy hatékony legyen az eltérő környezetben. Egy nyelv alaptípusai felett 
csak pürroszi győzelmet arathatunk. 


A C44 támogatja a fokozatos tanulást. Az, hogy hogyan közelítsünk egy új nyelv tanulásá- 
hoz, attól függ, mit tudunk már és mit akarunk még megtanulni. Nem létezik egyetlen 
megközelítés sem, amely mindenkinek jó lenne. A szerző feltételezi, hogy az olvasó azért 
tanulja a Ct-4-t, hogy jobb programozó és tervező legyen. Vagyis nem egyszerűen egy új 
nyelvtant akar megtanulni, mellyel a régi megszokott módon végzi a dolgokat, hanem új és 
jobb rendszerépítési módszereket akar elsajátítani. Ezt fokozatosan kell csinálni, mert min- 
den új képesség megszerzése időt és gyakorlást igényel. Gondoljuk meg, mennyi időbe ke- 
rülne jól megtanulni egy új természetes nyelvet vagy megtanulni jól játszani egy hangsze- 
ren. Könnyen és gyorsan lehetünk jobb rendszertervezők, de nem annyival könnyebben és 
gyorsabban, mint ahogy azt a legtöbben szeretnénk. 


Következésképpen a C-t--t — gyakran valódi rendszerek építésére — már azelőtt használni 
fogjuk, mielőtt megértenénk minden nyelvi tulajdonságot és eljárást. A C-t — azáltal, hogy 
több programozási modellt is támogat (2. fejezet) — különböző szintű szakértelem esetén is 
támogatja a termékeny programozást. Minden új programozási stílus újabb eszközt ad esz- 
köztárunkhoz, de mindegyik magában is hatékony és mindegyik fokozza a programozói 
hatékonyságot. A C-4--t úgy alkották meg, hogy a fogalmakat nagyjából sorban egymás 
után tanulhassuk meg és eközben gyakorlati haszonra tehessünk szert. Ez fontos, mert a ha- 
szon a kifejtett erőfeszítéssel arányos. 
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A folytatódó vita során — kell-e C-t tanulni a Ct-4-szal való ismerkedés előtt — szilárd meg- 
győződésemmé vált, hogy legjobb közvetlenül a C-4--ra áttérni. A Ct-4 biztonságosabb, ki- 
fejezőbb, csökkenti annak szükségét, hogy a figyelmet alacsonyszintű eljárásokra irányít- 
suk. Könnyebb a C-ben a magasabb szintű lehetőségek hiányát pótló trükkösebb részeket 
megtanulni, ha előbb megismertük a C és a C-s- közös részhalmazát és a C-4- által közvet- 
lenül támogatott magasabb szintű eljárásokat. A ,B" függelék vezérfonalat ad azoknak 
a programozóknak, akik a C-t ismeretében váltanak a C-re, például azért, hogy régebbi kó- 
dot kezeljenek. 


Több egymástól függetlenül fejlesztett és terjesztett Ct--változat létezik. Gazdag választék 
kapható eszköztárakból, könyvtárakból, programfejlesztő környezetekből is. Rengeteg tan- 
könyv, kézikönyv, folyóirat, elektronikus hirdetőtábla, konferencia, tanfolyam áll rendelke- 
zésünkre a Ct- legfrissebb fejlesztéseiről, használatáról, segédeszközeiről, könyvtárairól, 
megvalósításairól és így tovább. Ha az olvasó komolyan akarja a C---t használni, tanácsos 
az ilyen források között is böngészni. Mindegyiknek megvan a saját nézőpontja, elfogultsá- 
ga, ezért használjunk legalább kettőt közülük. Például lásd [Barton,1994], IBooch,1994], 
[Henricson, 19971], IKoenig, 1997], IMartin, 1995]. 


1.3. A Ct-- jellemzői 


Az egyszerűség fontos tervezési feltétel volt; ahol választani lehetett, hogy a nyelvet vagy 
a fordítót egyszerűsítsük-e, az előbbit választottuk. Mindenesetre nagy súlyt fektettünk ar- 
ra, hogy megmaradjon a C-vel való összeegyeztethetőség, ami eleve kizárta a C nyelvtan 
kisöprését. 


A C44-nak nincsenek beépített magasszintű adattípusai, sem magasszintű alapműveletei. 
A C4s4-ban például nincs mátrixtípus inverzió operátorral, karakterlánc-típus összefűző 
művelettel. Ha a felhasználónak ilyen típusra van szüksége, magában a nyelvben definíál- 
hat ilyet. Alapjában véve a C4--ban a legelemibb programozási tevékenység az általános 
célú vagy alkalmazásfüggő típusok létrehozása. Egy jól megtervezett felhasználói típus 
a beépített típusoktól csak abban különbözik, milyen módon határozták meg, abban nem, 
hogyan használják. A III. részben leírt standard könyvtár számos példát ad az ilyen típusok- 
ra és használatukra. A felhasználó szempontjából kevés a különbség egy beépített és egy 
standard könyvtárbeli típus között. 
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A C34-ban kerültük az olyan tulajdonságokat, melyek akkor is a futási idő növekedését 
vagy a tár túlterhelését okoznák, ha nem használjuk azokat. Nem megengedettek például 
azok a szerkezetek, melyek , háztartási információ" tárolását tennék szükségessé minden 
objektumban, így ha a felhasználó például két 16 bites mennyiségből álló szerkezetet ad 
meg, az egy 32 bites regiszterbe tökéletesen belefér. 


A C3--t hagyományos fordítási és futási környezetben való használatra tervezték, vagyis 
a UNIX rendszer C programozási környezetére. Szerencsére a C-t sohasem volt a UNIX-ra 
korlátozva, a UNIX-ot és a C-t csupán modellként használtuk a nyelv, a könyvtárak, a for- 
dítók, a szerkesztők, a futtatási környezetek stb. rokonsága alapján. Ez a minimális modell 
segítette a Ct- sikeres elterjedését lényegében minden számítógépes platformon. Jó okai 
vannak azonban a C-- használatának olyan környezetekben, melyek jelentősen nagyobb 
támogatásról gondoskodnak. Az olyan szolgáltatások, mint a dinamikus betöltés, a fokoza- 
tos fordítás vagy a típusmeghatározások adatbázisa, anélkül is jól használhatók, hogy befo- 
lyásolnák a nyelvet. 


A Cs típusellenőrzési és adatrejtési tulajdonságai a programok fordítási idő alatti elemzé- 
sére támaszkodnak, hogy elkerüljék a véletlen adatsérüléseket. Nem gondoskodnak titko- 
sításról vagy az olyan személyek elleni védelemről, akik szándékosan megszegik a szabá- 
lyokat. Viszont szabadon használhatók és nem járnak a futási idő vagy a szükséges tárhely 
növekedésével. Az alapelv az, hogy ahhoz, hogy egy nyelvi tulajdonság hasznos legyen, 
nemcsak elegánsnak, hanem valódi programon belül is elhelyezhetőnek kell lennie. 


A Cr jellemzőinek rendszerezett és részletes leírását lásd IStroustrup, 19941. 


1.3.1. Hatékonyság és szerkezet 


A Ct54-t a C programozási nyelvből fejlesztettük ki és — néhány kivételtől eltekintve — a C-t, 
mint részhalmazt, megtartotta. Az alapnyelvet, a Ct- C részhalmazát, úgy terveztük, hogy 
nagyon szoros megfelelés van típusai, műveletei, utasításai, és a számítógépek által közvet- 
lenül kezelhető objektumok (számok, karakterek és címek) között. A new, delete, tybeid, 
dynamic. cast és throw operátorok és - a try blokk - kivételével, az egyes Cs kifejezé- 
sek és utasítások nem kívánnak futási idejű támogatást. 


A C3- ugyanolyan függvényhívási és visszatérési módokat használhat, mint a C — vagy még 
hatékonyabbakat. Amikor még az ilyen, viszonylag hatékony eljárások is túl költségesek, 
a C4-4 függvényt a fordítóval kifejtethetjük helyben (inline kód), így élvezhetjük a függvé- 
nyek használatának kényelmét, a futási idő növelése nélkül. 
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A C egyik eredeti célja az assembly kód helyettesítése volt a legigényesebb rendszerprog- 
ramozási feladatokban. Amikor a C----t terveztük, vigyáztunk, ne legyen megalkuvás e té- 
ren. A C és a Cs közti különbség elsősorban a típusokra és adatszerkezetekre fektetett súly 
mértékében van. A C kifejező és elnéző. A C-- még kifejezőbb. Ezért a jobb kifejezőképes- 
ségért cserébe azonban nagyobb figyelmet kell fordítanunk az objektumok típusára. A for- 
dító az objektumok típusának ismeretében helyesen tudja kezelni a kifejezéseket akkor is, 
ha egyébként kínos precizitással kellett volna megadni a műveleteket. Az objektumok típu- 
sának ismerete arra is képessé teszi a fordítót, hogy olyan hibákat fedjen fel, melyek más- 
különben egészen a tesztelésig vagy még tovább megmaradnának. Vegyük észre, hogy a tí- 
pusrendszer használata függvényparaméterek ellenőrzésére — az adatok véletlen sérüléstől 
való megvédésére, új típusok vagy operátorok előállítására és így tovább — a C--t-ban nem 
növeli a futási időt vagy a szükséges helyet. 


A C44-ban a szerkezetre fektetett hangsúly tükrözi a C megtervezése óta megírt programok 
,súlygyarapodását". Egy kis — mondjuk 1000 soros — programot megírhatunk , nyers erővel", 
még akkor is, ha felrúgjuk a jó stílus minden szabályát. Nagyobb programoknál ez egyszerű- 
en nincs így. Ha egy 100 000 soros programnak rossz a felépítése, azt fogjuk találni, hogy 
ugyanolyan gyorsan keletkeznek az újabb hibák, mint ahogy a régieket eltávolítjuk. A C----t 
úgy terveztük, hogy lehetővé tegye nagyobb programok ésszerű módon való felépítését, így 
egyetlen személy is sokkal nagyobb kódmennyiséggel képes megbirkózni. Ezenkívül célkitű- 
zés volt, hogy egy átlagos sornyi Ct-t kód sokkal többet fejezzen ki, mint egy átlagos Pascal 
vagy C kódsor. A C4- mostanra megmutatta, hogy túl is teljesíti ezeket a célkitűzéseket. 


Nem minden kódrészlet lehet jól szerkesztett, hardverfüggetlen vagy könnyen olvasható. 
A C44-nak vannak tulajdonságai, melyeket arra szántak, hogy közvetlen és hatékony mó- 
don kezelhessük a hardver szolgáltatásait, anélkül, hogy a biztonságra vagy az érthetőség- 
re káros hatással lennénk. Vannak olyan lehetőségei is, melyekkel az ilyen kód elegáns és 
biztonságos felületek mögé rejthető. 


A C4t4 nagyobb programokhoz való használata természetszerűen elvezet a Ct-t nyelv 
programozócsoportok általi használatához. A C-- által a modularitásra, az erősen típusos 
felületekre és a rugalmasságra fektetetett hangsúly itt fizetődik ki. A C4--nak éppen olyan 
jól kiegyensúlyozott szolgáltatásai vannak nagy programok írására, mint bármely nyelvnek. 
Ahogy nagyobbak lesznek a programok, a fejlesztésükkel és fenntartásukkal, módosításuk- 
kal kapcsolatos problémák a , nyelvi probléma" jellegtől az eszközök és a kezelés általáno- 
sabb problémái felé mozdulnak el. A IV. rész ilyen jellegű kérdéseket is tárgyal. 
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Könyvünk kiemeli az általános célú szolgáltatások, típusok és könyvtárak készítésének 
módjait. Ezek éppúgy szolgálják a kis programok íróit, mint a nagy programokéit. Ezen túl- 
menően, mivel minden bonyolultabb program sok, félig-meddig független részből áll, az 
ilyen részek írásához szükséges módszerek ismerete jó szolgálatot tesz minden alkalmazás- 
programozónak. 


Az olvasó azt gondolhatja, a részletesebb típusszerkezetek használata nagyobb forrásprog- 
ramhoz vezet. A C-t esetében ez nem így van. Egy Ct-t program, amely függvényparamé- 
ter-típusokat vezet be vagy osztályokat használ, rendszerint kissé rövidebb, mint a vele 
egyenértékű C program, amely nem használja e lehetőségeket. Ott, ahol könyvtárakat hasz- 
nálnak, egy Ct4 program sokkal rövidebb lesz, mint a megfelelő C program, feltéve termé- 
szetesen, hogy készíthető működőképes C-beli megfelelő. 


1.3.2. Filozófiai megjegyzés 


A programozási nyelvek két rokon célt szolgálnak: a programozónak részben eszközt ad- 
nak, amellyel végrehajtható műveleteket adhat meg, ugyanakkor egy sereg fogódzót is ren- 
delkezésére bocsátanak, amikor arról gondolkodik, mit lehet tenni. Az első cél ideális eset- 
ben , gépközeli" nyelvet kíván, amellyel a számítógép minden fontos oldala egyszerűen és 
hatékonyan kezelhető, a programozó számára ésszerű, kézenfekvő módon. A C nyelvet el- 
sősorban ebben a szellemben tervezték. A második cél viszont olyan nyelvet követel meg, 
mely , közel van a megoldandó problémához", hogy a megoldás közvetlenül és tömören ki- 
fejezhető legyen. 


A nyelv, melyben gondolkodunk/programozunk és a problémák, megoldások, melyeket el 
tudunk képzelni, szoros kapcsolatban állnak egymással. Ezért a nyelvi tulajdonságok meg- 
szorítása azzal a szándékkal, hogy kiküszöböljük a programozói hibákat, a legjobb esetben 
is veszélyes. A természetes nyelvekhez hasonlóan nagy előnye van annak, ha az ember leg- 
alább két nyelvet ismer. A nyelv ellátja a programozót a megfelelő eszközökkel, ha azon- 
ban ezek nem megfelelőek a feladathoz, egyszerűen figyelmen kívül hagyjuk azokat. A jó 
tervezés és hibamentesség nem biztosítható csupán az egyedi nyelvi tulajdonságok jelenlé- 
tével vagy távollétével. 


A típusrendszer különösen összetettebb feladatok esetében jelent segítséget. A C-t-4 osztá- 
lyai valóban erős eszköznek bizonyultak. 
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1.4. Történeti megjegyzés 


A szerző alkotta meg a C4--t, írta meg első definícióit, és készítette el első változatát. Meg- 
választotta és megfogalmazta a C--- tervezési feltételeit, megtervezte fő szolgáltatásait, és ő 


volt a felelős a C4- szabványügyi bizottságban a bővítési javaslatok feldolgozásáért. 


Világos, hogy a C-t sokat köszönhet a C-nek IKernighan, 1978]. A C néhány, a típusellen- 
őrzés terén tapasztalt hiányosságát kivéve megmaradt, részhalmazként (lásd , B" függelék). 
Ugyancsak megmaradt az a C-beli szándék, hogy olyan szolgáltatásokra fektessen hang- 
súlyt, melyek elég alacsony szintűek ahhoz, hogy megbirkózzanak a legigényesebb rend- 
szerprogramozási feladatokkal is. A C a maga részéről sokat köszönhet ősének, a BCPL-nek 
(Richards, 1980]; a BEPL / megjegyzés-formátuma (újra) be is került a C4---ba. A C4t-4 má- 
sik fontos forrása a Simula67 volt [Dahl, 1970] [Dahl, 1972]; az osztály fogalmát (a származ- 
tatott osztályokkal és virtuális függvényekkebD) innen vettem át. A C4- operátor-túlterhelési 
lehetősége és a deklarációk szabad elhelyezése az utasítások között az Algoló8-ra emlékez- 
tet (Woodward, 19741]. 


A könyv eredeti kiadása óta a nyelv kiterjedt felülvizsgálatokon és finomításokon ment 
keresztül. A felülvizsgálatok fő területe a túlterhelés feloldása, az összeszerkesztési és tár- 
kezelési lehetőségek voltak. Ezenkívül számos kisebb változtatás történt a C-vel való kom- 
patibilitás növelésére. Számos általánosítás és néhány nagy bővítés is belekerült: ezek 
a többszörös öröklés, a static és const tagfüggvények, a protected tagok, a sablonok, a ki- 
vételkezelés, a futási idejű típusazonosítás és a névterek. E bővítések és felülvizsgálatok 
átfogó feladata a Ct4 olyan nyelvvé fejlesztése volt, mellyel jobban lehet könyvtárakat írni 


és használni. A C4-- fejlődésének leírását lásd IStroustrup, 19941]. 


A sablonok (template) bevezetésének elsődleges célja a statikus típusú tárolók (konténerek 
— list, vector, map) és azok hatékony használatának (általánosított vagy generikus progra- 
mozás) támogatása, valamint a makrók és explicit típuskényszerítések (casting) szükségé- 
nek csökkentése volt. Inspirációt az Ada általánosító eszközei (mind azok erősségei, illetve 
gyengeségei), valamint részben a Clu paraméteres moduljai szolgáltattak. Hasonlóan, a Cr 
kivételkezelési eljárásainak elődjei is többé-kevésbé az Ada [Ichbiah, 1979], a Clu [Liskov, 
1979] és az ML [Wikstrm, 1987]. Az 1985-1995 között bevezetett egyéb fejlesztések — több- 
szörös öröklés, tisztán virtuális függvények és névterek — viszont nem annyira más nyelvek- 
ből merített ötletek alapján születtek, inkább a C--- használatának tapasztalataiból leszűrt 
általánosítások eredményei. 


A nyelv korábbi változatait (összefoglaló néven az osztályokkal bővített C-t IStroustrup, 
1994D 1980 óta használják. Kifejlesztésében eredetileg szerepet játszott, hogy olyan ese- 
ményvezérelt szimulációkat szerettem volna írni, melyekhez a Simula67 ideális lett volna, 
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ha eléggé hatékony. Az , osztályokkal bővített C" igazi területét a nagy programok jelentet- 
ték, ahol a lehető leggyorsabbnak kell lenni és a lehető legkevesebb helyet foglalni. Az el- 
ső változatokból még hiányzott az operátor-túlterhelés, valamint hiányoztak a referenciák, 
a virtuális függvények, a sablonok, a kivételek és sok egyéb. A C-4--t nem kísérleti körül- 
mények között először 1983-ban használták. 


A C44 nevet Rick Mascitti adta a nyelvnek az említett év nyarán. A név kifejezi mindazt 
a forradalmi újítást, amit az új nyelv a C-hez képest hozott: a 4-4 a C növelő műveleti jele. 
(A ,C4"-t is használják, de az egy másik, független nyelv.) A C utasításformáit jól ismerők 
rámutathatnak, hogy a ,Ct4" kifejezés nem olyan ,erős", mint a ,t44C". Mindazonáltal 
a nyelv neve nem is D, hiszen a C-nek csupán bővítéséről van szó, amely az ott felmerült 
problémák elhárításához az eredeti nyelv szolgáltatásai közül egyet sem vet el. A C-t név 


más megközelítésű elemzéséhez lásd [Orwell, 1949, függelék]. 


A C4t4 megalkotásának fő oka azonban az volt, hogy barátaimmal együtt nem szerettünk 
volna assembly, C vagy más modern, magas szintű nyelven programozni. Csak annyit akar- 
tunk elérni, hogy könnyebben és élvezetesebben írhassunk jól használható programokat. 
Kezdetben nem vetettük papírra rendszerezetten a fejlesztési terveket: egyszerre tervez- 
tünk, dokumentáltunk és alkottunk. Nem volt , Cst projekt" vagy ,C44 tervezőbizottság" . 
A C44 a felhasználók tapasztalatai és a barátaimmal, munkatársaimmal folytatott viták so- 
rán fejlődött ki. 

A C44 későbbi robbanásszerű elterjedése szükségszerűen változásokat hozott magával. Va- 
lamikor 1987-ben nyilvánvalóvá vált, hogy a C4- hivatalos szabványosítása immár elkerül- 
hetetlen és haladéktalanul meg kell kezdenünk az ilyen irányú munka előkészítését 
IStroustrup, 1994]. Folyamatosan próbáltuk tartani a kapcsolatot mind hagyományos, mind 
elektronikus levélben, illetve személyesen, konferenciákat tartva a különböző C--- fordítók 
készítőivel és a nyelv fő felhasználóival. 


Ebben a munkában nagy segítséget nyújtott az ATXKT Bell Laboratories, lehetővé téve, hogy 
vázlataimat és a Ct- hivatkozási kézikönyv újabb és újabb változatait megoszthassam a fej- 
lesztőkkel és felhasználókkal. Segítségük nem alábecsülendő, ha tudjuk, hogy az említettek 
nagy része olyan vállalatoknál dolgozott, amelyek az ATXT vetélytársainak tekinthetők. 
Egy kevésbé , felvilágosult" cég komoly problémákat okozhatott volna és a nyelv , tájszólás- 
okra" töredezését idézte volna elő, pusztán azáltal, hogy nem tesz semmit. Szerencsére a tu- 
catnyi cégnél dolgozó mintegy száz közreműködő elolvasta és megjegyzésekkel látta el 
a vázlatokat, melyekből az általánosan elfogadott hivatkozási kézikönyv és a szabványos 
ANSI Ct4 alapdokumentuma megszületett. A munkát segítők neve megtalálható a 77e 
Annotated Ct4 Reference Manual-ban IEllis, 1989]. Végül az ANSI X3J16 bizottsága a Hew- 
lett-Packard kezdeményezésére 1989 decemberében összeült, 1991 júniusában pedig már 
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annak örülhettünk, hogy az ANSI (az amerikai nemzeti szabvány) C4- az ISO (nemzetkö- 
zi) Ct4 szabványosítási kezdeményezés részévé vált. 1990-től ezek a szabványügyi bizott- 
ságok váltak a nyelv fejlesztésének és pontos körülhatárolásának fő fórumaivá. Magam 
mindvégig részt vettem e bizottságok munkájában; a bővítményekkel foglalkozó munka- 
csoport elnökeként közvetlenül feleltem a C4--t érintő lényegbevágó módosítási javaslatok 
és az új szolgáltatások bevezetését szorgalmazó kérelmek elbírálásáért. Az első szabvány- 
vázlat 1995 áprilisában került a nagyközönség elé, a végleges ISO C4- szabványt (ISO/IEC 


14882) pedig 1998-ban fogadták el. 


A könyvben bemutatott kulcsfontosságú osztályok némelyike a C-----szal párhuzamosan fej- 
lődött. A complex, vector és stack osztályokat például az operátor-túlterhelési eljárásokkal 
egyidőben dolgoztam ki. A karakterlánc- és listaosztályokat (sztring, list) Jonathan 
Shopironak köszönhetjük (azért én is közreműködtem). Jonathan hasonló osztályai voltak 
az elsők, amelyeket egy könyvtár részeként széles körben használtak; ezekből a régi kísér- 
letekből fejlesztettük ki a C- standard könyvtárának string osztályát. A [Stroustrup, 19871] 
és a §12.7I11] által leírt tas£ könyvtár egyike volt az , osztályokkal bővített C" nyelven elő- 
ször írt programoknak. (A könyvtárat és a kapcsolódó osztályokat én írtam a Simula stílusú 
szimulációk támogatásához.) A könyvtárat később Jonathan Shopiro átdolgozta, és még ma 
is használják. Az első kiadásban leírt stream könyvtárat én terveztem és készítettem el, Jerry 
Schwarz pedig Andrew Koenig formázó eljárása (421.4.6) és más ötletek felhasználásával az 
e könyv 21. fejezetében bemutatandó iostreams könyvtárrá alakította. A szabványosítás so- 
rán a könyvtár további finomításon esett át; a munka dandárját Jerry Schwarz, Nathan Myers 
és Norihiro Kumagai végezték. A sablonok lehetőségeit az Andrew Koenig, Alex Stepanov, 
személyem és mások által tervezett vector, map, list és sort sablonok alapján dolgoztuk ki. 
Alex Stepanovnak a sablonokkal történő általánosított programozás terén végzett munkája 
emellett elvezetett a tárolók bevezetéséhez és a C-- standard könyvtárának egyes algorit- 
musaihoz is (416.3, 17. fejezet, 18. fejezet §19.2). A számokkal végzett műveletek valarray 
könyvtára (22. fejezet) nagyrészt Kent Budge munkája. 


1.5. A C-t használata 


A C44-t programozók százezrei használják, lényegében minden alkalmazási területen. Ezt 
a használatot támogatja tucatnyi független megvalósítás, többszáz könyvtár és tankönyv, 
számos műszaki folyóirat, konferencia, és számtalan konzultáns. Oktatás és képzés minden 
szinten, széles körben elérhető. 
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A régebbi alkalmazások erősen a rendszerprogramozás felé hajlottak. Több nagy operációs 
rendszer íródott Ct-4-ban: [Campbell, 1987] IRozier, 1988] [Hamilton, 1993] [Berg, 1995] 
IParrington, 1995] és sokan mások kulcsfontosságú részeket írtak. A szerző lényegesnek te- 
kinti a C44 engedmény nélküli gépközeliségét, ami lehetővé teszi, hogy C-4--ban írhassunk 
eszközmeghajtókat és más olyan programokat, melyek valósidejű, közvetlen hardverkezelés- 
re támaszkodnak. Az ilyen kódban a működés kiszámíthatósága legalább annyira fontos, mint 
a sebesség és gyakran így van az eredményül kapott rendszer tömörségével is. A C---t úgy 
terveztük, hogy minden nyelvi tulajdonság használható legyen a komoly időbeli és helyfog- 
lalásbeli megszorításoknak kitett kódban is. IStroustrup, 1994, §4.5]. 


A legtöbb programban vannak kódrészletek, melyek létfontosságúak az elfogadható telje- 
sítmény tekintetében. A kód nagyobb részét azonban nem ilyen részek alkotják. A legtöbb 
kódnál a módosíthatóság, a könnyű bővíthetőség és tesztelhetőség a kulcskérdés. A C4- 
ilyen téren nyújtott támogatása vezetett el széleskörű használatához ott, ahol kötelező 
a megbízhatóság, és ahol az idő haladtával jelentősen változnak a követelmények. Példa- 
ként a bankok, a kereskedelem, a biztosítási szféra, a távközlés és a katonai alkalmazások 
szolgálhatnak. Az USA távolsági telefonrendszere évek óta a C-ra támaszkodik és minden 
800-as hívást (vagyis olyan hívást, ahol a hívott fél fizet) Ct-t program irányít IKamath, 
1993]. Számos ilyen program nagy méretű és hosszú életű. Ennek eredményképpen a sta- 
bilitás, a kompatibilitás és a méretezhetőség állandó szempontok a C-- fejlesztésében. 
Nem szokatlanok a millió soros C--- programok. 


A C-hez hasonlóan a C-r--t sem kifejezetten számokkal végzett műveletekhez tervezték. 
Mindazonáltal sok számtani, tudományos és mérnöki számítást írtak C----ban. Ennek fő 
oka, hogy a számokkal való hagyományos munkát gyakran grafikával és olyan számítások- 
kal kell párosítani, melyek a hagyományos Fortran mintába nem illeszkedő adatszerkeze- 
tekre támaszkodnak [Budge, 1992] [Barton, 1994]. A grafika és a felhasználói felület olyan 
területek, ahol erősen használják a C----t. Bárki, aki akár egy Apple Macintosht, akár egy 
Windowst futtató PC-t használt, közvetve a C4--t használta, mert e rendszerek elsődleges 
felhasználói felületeit Ct-- programok alkotják. Ezenkívül a UNIX-ban az X-et támogató leg- 
népszerűbb könyvtárak némelyike is C---ban íródott. Ilyenformán a C$-4 közösen válasz- 
tott nyelve annak a hatalmas számú alkalmazásnak, ahol a felhasználói felület kiemelt fon- 
tosságú. 


Mindezen szempontok mellett lehet, hogy a Cs legnagyobb erőssége az a képessége, hogy 
hatékonyan használható olyan programokhoz, melyek többféle alkalmazási területen igé- 
nyelnek munkát. Egyszerű olyan alkalmazást találni, melyben LAN és WAN hálózatot, 
számokkal végzett műveleteket, grafikát, felhasználói kölcsönhatást és adatbázis-hozzáférést 
használunk. Az ilyen alkalmazási területeket régebben különállóknak tekintették és általá- 
ban különálló fejlesztőközösségek szolgálták ki, többféle programozási nyelvet használva. 
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A C-34-t széles körben használják oktatásra és kutatásra. Ez néhány embert meglepett, 
akik — helyesen — rámutattak, hogy a C-t nem a legkisebb és legtisztább nyelv, amelyet va- 
laha terveztek. Mindazonáltal a C4- 


6 elég tiszta ahhoz, hogy az alapfogalmakat sikeresen tanítsuk, 
elég valószerű, hatékony és rugalmas az igényes projektekhez is, 
6 elérhető olyan szervezetek és együttműködő csoportok számára, melyek eltérő 


hd 


fejlesztési és végrehajtási környezetekre támaszkodnak, 

6 elég érthető ahhoz, hogy bonyolult fogalmak és módszerek tanításának hordo- 
zója legyen és 

6 elég , kereskedelmi", hogy segítse a tanultak gyakorlatban való felhasználását. 


A C45 olyan nyelv, mellyel gyarapodhatunk. 


1.6. C és C-t 


A C44 alapnyelvének a C nyelvet választottuk, mert 


sokoldalú, tömör, és viszonylag alacsony szintű, 
megfelel a legtöbb rendszerprogramozási feladatra, 
mindenütt és mindenen fut, és 


.... 


illeszkedik a UNIX programozási környezetbe. 


A C-nek megvannak a hibái, de egy újonnan készített nyelvnek is lennének, a C problémá- 
it pedig már ismerjük. Nagy jelentősége van, hogy C-vel való munka vezetett el a hasznos 


(bár nehézkes) eszközzé váló , osztályokkal bővített C"-hez, amikor először gondoltunk a C 
bővítésére Simula-szerű osztályokkal. 


Ahogy szélesebb körben kezdték használni a C-----t és az általa nyújtott, a C lehetőségeit fe- 
lülmúló képességek jelentősebbek lettek, újra és újra felmerült a kérdés, megtartsuk-e a két 
nyelv összeegyeztethetőségét. Világos, hogy néhány probléma elkerülhető lett volna, ha 
némelyik C örökséget elutasítjuk (lásd pl. ISethi, 1981]. Ezt nem tettük meg, a következők 
miatt: 
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1. Több millió sornyi C kód van, mely élvezheti a C---- előnyeit, feltéve, hogy 
szükségtelen a C-ről C4--ra való teljes átírás. 

2. Több millió sornyi C-ben írt könyvtári függvény és eszközillesztő kód van, me- 
lyet Ct-t programokból/programokban használni lehet, feltéve, hogy a C-t 
program összeszerkeszthető és formailag összeegyeztethető a C programmal. 

3. Programozók százezrei léteznek, akik ismerik a C-t és ezért csak a C- új tulaj- 
donságait kell megtanulniuk, vagyis nem kell az alapokkal kezdeniük. 

4. A C-t és a C-t ugyanazok, ugyanazokon a rendszereken fogják évekig hasz- 
nálni, tehát a különbségek vagy nagyon nagyok, vagy nagyon kicsik lesznek, 
hogy a hibák és a keveredés lehetősége a lehető legkisebbre csökkenjen. 


A Cs34-t felülvizsgáltuk, hogy biztosítsuk, hogy azon szerkezetek, melyek mind a C-ben, 
mind a C4-4-ban megengedettek, mindkét nyelvben ugyanazt jelentsék (Y§B.2). 


A C nyelv maga is fejlődött, részben a C4-- fejlesztésének hatására IRosler, 1984]. Az ANSI C 
szabvány IC,1990] a függvénydeklarációk formai követelményeit az , osztályokkal bővített 
C"-ből vette át. Az átvétel mindkét irányban előfordul: a void?" mutatótípust például az ANSI 
C-hez találták ki, de először a C4--ban valósították meg. Mint ahogy e könyv első kiadásá- 
ban megígértük, a C-4--t felülvizsgáltuk, hogy eltávolítsuk az indokolatlan eltéréseket, így 
a Ct4t ma jobban illeszkedik a C-hez, mint eredetileg. Az elképzelés az volt, hogy a Cr 
olyan közel legyen az ANSI C-hez, amennyire csak lehetséges — de ne közelebb IKoenig, 
1989]. A száz százalékos megfelelőség soha nem volt cél, mivel ez megalkuvást jelentene 
a típusbiztonságban, valamint a felhasználói és beépített típusok zökkenésmentes egyezte- 
tésében. 


A C tudása nem előfeltétele a Ctt megtanulásának. A C programozás sok olyan módszer és 
trükk használatára biztat, melyeket a C$-4 nyelvi tulajdonságai szükségtelenné tettek. Az 
explicit típuskényszerítés például ritkábban szükséges a C---ban, mint a C-ben (§1.6.1). 
A jó C programok azonban hajlanak a C4- programok felé. A Kernighan és Ritchie féle 
A C programozási nyelv (Műszaki könyvkiadó, második kiadás, 1994) IKernighan,1988] 
című kötetben például minden program C-t-t program. Bármilyen statikus típusokkal ren- 
delkező nyelvben szerzett tapasztalat segítséget jelent a C-t tanulásánál. 


1.6.1. Javaslatok C programozóknak 


Minél jobban ismeri valaki a C-t, annál nehezebbnek látja annak elkerülését, hogy C stílus- 
ban írjon Ct4 programot, lemondva ezáltal a C4- előnyeiről. Kérjük, vessen az olvasó egy 
pillantást a ,B" függelékre, mely leírja a C és a Cr közti különbségeket. Íme néhány terü- 
let, ahol a C-t fejlettebb, mint a C: 
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1. A C4-4-ban a makrókra majdnem soha sincs szükség. A névvel ellátott állandók 
meghatározására használjunk konstanst (consD (§45.4) vagy felsorolást (enum 
(44.38), a függvényhívás okozta többletterhelés elkerülésére helyben kifejtett 
függvényeket (§7.1.1), a függvény- és típuscsaládok leírására sablonokat 
(13. fejezet), a névütközések elkerülésére pedig névtereket (§8.2). 

2. Ne vezessünk be egy változót, mielőtt szükség van rá, így annak azonnal 
kezdőértéket is adhatunk. Deklaráció bárhol lehet, ahol utasítás lehet (46.3.1), 
így for utasítások (46.3.3) és elágazások feltételeiben (§6.3.2.1) is. 

3. Ne használjunk mallocO-ot, a new operátor (46.2.60) ugyanazt jobban elvégzi. 
A reallocO helyett próbáljuk meg a vector-t (§3.8). 

4. Próbáljuk elkerülni a void" mutatókkal való számításokat, az uniókat és típus- 
konverziókat (típusátalakításokat), kivéve, ha valamely függvény vagy osztály 
megvalósításának mélyén találhatók. A legtöbb esetben a típuskonverzió a ter- 
vezési hiba jele. Ha feltétlenül erre van szükség, az ,új cast-ok" (46.2.7) egyikét 
próbáljuk használni szándékunk pontosabb leírásához. 

5. Csökkentsük a lehető legkevesebbre a tömbök és a C stílusú karakterláncok 
használatát. A Ct-4 standard könyvtárának string (43.5) és vector (§3.7.1) osztá- 
lyai a hagyományos C stílushoz képest gyakrabban használhatók a programozás 
egyszerűbbé tételére. Általában ne próbáljunk magunk építeni olyat, ami meg- 
van a standard könyvtárban. 


Ahhoz, hogy eleget tegyünk a C szerkesztési szabályainak, a C-t függvényeket úgy kell 
megadnunk, hogy szerkesztésük C módú legyen. (49.2.4). A legfontosabb, hogy úgy pró- 
báljunk egy programot elképzelni, mint egymással kölcsönhatásban lévő fogalmakat, me- 
lyeket osztályok és objektumok képviselnek, nem pedig úgy, mint egy halom adatszerke- 
Zetet, a bitekkel zsonglőrködő függvényekkel. 


1.6.2. Javaslatok C--- programozóknak 


Sokan már egy évtized óta használják a C----t. Még többen használják egyetlen környezet- 
ben és tanultak meg együtt élni a korai fordítók és első generációs könyvtárak miatti korlá- 
tozásokkal. Ami a tapasztalt Ct-4 programozók figyelmét gyakran elkerüli, nem is annyira 
az új eszközök megjelenése, mint inkább ezen eszközök kapcsolatainak változása, ami 
alapjaiban új programozási módszereket követel meg. Más szóval, amire annak idején nem 
gondoltunk vagy haszontalannak tartottunk, ma már kiváló módszerré válhatott, de ezekre 
csak az alapok újragondolásával találunk rá. 
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Olvassuk át a fejezeteket sorban. Ha már ismerjük a fejezet tartalmát, gondolatban ismétel- 
jük át. Ha még nem ismerjük, valami olyat is megtanulhatunk, amire eredetileg nem számí- 
tottunk. Én magam elég sokat tanultam e könyv megírásából, és az a gyanúm, hogy kevés 
C4-4 programozó ismeri az összes itt bemutatott összes eszközt és eljárást. Ahhoz, hogy he- 
lyesen használjunk egy nyelvet, behatóan kell ismernünk annak eszközeit, módszereit. Fel- 


építése és példái alapján ez a könyv megfelelő rálátást biztosít. 


1.7. Programozási megfontolások a C---t--ban 


A programtervezést ideális esetben három fokozatban közelítjük meg. Először tisztán érthe- 
tővé tesszük a problémát (elemzés, analízis), ezután azonosítjuk a fő fogalmakat, melyek 
egy megoldásban szerepelnek (tervezés), végül a megoldást egy programban fejezzük ki 
(programozás). A probléma részletei és a megoldás fogalmai azonban gyakran csak akkor 
válnak tisztán érthetővé, amikor egy elfogadhatóan futtatható programban akarjuk kifejez- 
ni azokat. Ez az, ahol számít, milyen programozási nyelvet választunk. 


A legtöbb alkalmazásban vannak fogalmak, melyeket nem könnyű a kapcsolódó adatok 
nélkül az alaptípusok egyikével vagy függvénnyel ábrázolni. Ha adott egy ilyen fogalom, 
hozzunk létre egy osztályt, amely a programban képviselni fogja. A Ct- osztályai típusok, 
melyek meghatározzák, hogyan viselkednek az osztályba tartozó objektumok, hogyan jön- 
nek létre, hogyan kezelhetők és hogyan szűnnek meg. Az osztály leírhatja azt is, hogyan 
jelennek meg az objektumok, bár a programtervezés korai szakaszában ez nem szükség- 
szerűen fő szempont. Jó programok írásánál az a legfontosabb, hogy úgy hozzunk létre osz- 
tályokat, hogy mindegyikük egyetlen fogalmat, tisztán ábrázoljon. Ez általában azt jelenti, 
hogy a következő kérdésekre kell összpontosítani: Hogyan hozzuk létre az osztály objek- 
tumait? Másolhatók-e és/vagy megsemmisíthetők-e az osztály objektumai? Milyen művele- 
tek alkalmazhatók az objektumokra? Ha nincsenek jó válaszok e kérdésekre, az a legvaló- 
színűbb, hogy a fogalom nem , tiszta". Ekkor jó ötlet, ha tovább gondolkodunk a problémán 
és annak javasolt megoldásán, ahelyett, hogy azonnal elkezdenénk a kód kidolgozását. 


A legkönnyebben kezelhető fogalmak azok, amelyeknek hagyományos matematikai megfo- 
galmazásuk van: mindenfajta számok, halmazok, geometriai alakzatok stb. A szövegközpon- 
tú bemenet és kimenet, a karakterláncok, az alaptárolók, az ezekre a tárolókra alkalmazható 
alap-algoritmusok, valamint néhány matematikai osztály a C- standard könyvtárának részét 
képezik G. fejezet, §16.1.2). Ezenkívül elképesztő választékban léteznek könyvtárak, melyek 
általános és részterületekre szakosodott elemeket támogatnak. 
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Az egyes fogalmak (és a hozzájuk kapcsolódó elemek) nem légüres térben léteznek, min- 
dig rokonfogalmak csoportjába tartoznak. Az osztályok közti kapcsolatok szervezése egy 
programon belül — vagyis az egy megoldásban szereplő különböző elemek közti pontos 
kapcsolatok meghatározása — gyakran nehezebb, mint az egyes osztályokat kijelölni. Jobb, 
ha az eredmény nem rendetlenség, melyben minden osztály függ minden másiktól. 
Vegyünk két osztályt: A-t és B-t. Az olyan kapcsolatok, mint az , A hív B-beli függvényeket", 
, A létrehoz B-ket" és , A-nak van egy B tagja" ritkán okoznak nagy problémát, míg az olya- 
nok, mint az , A használ B-beli adatot" rendszerint kiküszöbölhetők. 


Az összetettség kezelésének egyik legerősebb eszköze a hierarchikus rendezés, vagyis a ro- 
kon elemek faszerkezetbe szervezése, ahol a fa gyökere a legáltalánosabb elem. A C----ban 
a származtatott osztályok ilyen fastruktúrákat képviselnek. Egy program gyakran úgy szer- 
vezhető, mint fák halmaza, vagy mint osztályok irányított körmentes gráfja. Vagyis a prog- 
ramozó néhány alaposztályt hoz létre, melyekhez saját származtatott osztályaik halmaza 
tartozik. Az elemek legáltalánosabb változatának (a bázisosztálynak) a kezelését végző mű- 
veletek meghatározására a virtuális függvényeket (§2.5.5, §12.2.6) használhatjuk. Szükség 
esetén ezen műveletek megvalósítása az egyedi esetekben (a származtatott osztályoknál) 
finomítható. 


Néha még az irányított körmentes gráf sem látszik kielégítőnek a programelemek szervezé- 
sére; egyes elemek kölcsönös összefüggése öröklöttnek tűnik. Ilyen esetben megpróbáljuk 
a ciklikus függőségeket behatárolni, hogy azok ne befolyásolják a program átfogó rendsze- 
rét. Ha nem tudjuk kiküszöbölni vagy behatárolni az ilyen kölcsönös függéseket, valószí- 
nű, hogy olyan gondban vagyunk, melyből nincs programozási nyelv, amely kisegítene. 
Hacsak ki nem tudunk eszelni könnyen megállapítható kapcsolatokat az alapfogalmak kö- 
zött, valószínű, hogy a program kezelhetetlenné válik. A függőségi gráfok kibogozásának 
egyik eszköze a felület (interfész) tiszta elkülönítése a megvalósítástól (implementáció). 
A C44 erre szolgáló legfontosabb eszközei az absztrakt osztályok (42.5.4, 12.39. 


A közös tulajdonságok kifejezésének másik formája a sablon (template, §2.7, 13. fejeze). Az 
osztálysablonok osztályok családját írják le. Egy listasablon például a , T elemek listáját" ha- 
tározza meg, ahol , I" bármilyen típus lehet. A sablon tehát azt adja meg, hogyan hozhatunk 
létre egy típust egy másik típus, mint paraméter átadásával. A legszokásosabb sablonok az 
olyan tárolóosztályok, mint a listák, tömbök és asszociatív tömbök, valamint az ilyen táro- 
lókat használó alap-algoritmusok. Rendszerint hiba, ha egy osztály és a vele kapcsolatos 
függvények paraméterezését öröklést használó típussal fejezzük ki. A legjobb sablonokat 
használni. 
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Emlékeztetünk arra, hogy sok programozási feladat egyszerűen és tisztán elvégezhető ele- 
mi típusok, adatszerkezetek, világos függvények és néhány könyvtári osztály segítségével. 
Az új típusok leírásában szereplő teljes apparátust nem szabad használni, kivéve, ha való- 
ban szükség van rá. 


A , Hogyan írjunk C-4--ban jó programot?" nagyon hasonlít a , Hogyan írjunk jó prózát?" kér- 
désre. Két válasz van: , Tudnunk kell, mit akarunk mondani" és , Gyakoroljunk. Színleljük 


a jó írást." Mind a kettő éppúgy helytálló a Cs, mint bármely természetes nyelv esetében — 
és tanácsukat éppolyan nehéz követni. 


1.8. Tanácsok 


Íme néhány , szabály" , amelyet figyelembe vehetünk a C-- tanulásakor. Ahogy jártasabbak 
leszünk, továbbfejleszthetjük ezeket saját programfajtáinkhoz, programozási stílusunkhoz 
illeszkedően. A szabályok szándékosan nagyon egyszerűek, így nélkülözik a részleteket. 
Ne vegyük őket túlzottan komolyan: a jó programok írásához elsősorban intelligencia, íz- 
lés, türelem kell. Ezeket nem fogjuk elsőre elsajátítani. Kísérletezzünk! 


[1] Amikor programozunk, valamilyen probléma megoldására született ötleteink konk- 
rét megvalósítását hozzuk létre. Tükrözze a program szerkezete olyan közvetlenül 
ezeket az ötleteket, amennyire csak lehetséges: 

a) Ha valamire úgy gondolunk, mint külön ötletre, tegyük osztállyá. 

b) Ha különálló egyedként gondolunk rá, tegyük egy osztály objektumává. 

c) Ha két osztálynak van közös felülete, tegyük ezt a felületet absztrakt osztállyá. 

d) Ha két osztály megvalósításában van valami közös, tegyük bázisosztállyá e 
közös tulajdonságokat. 

e) Ha egy osztály objektumok tárolója, tegyük sablonná. 

ff) Ha egy függvény egy tároló számára való algoritmust valósít meg, tegyük 
függvénysablonná, mely egy tárolócsalád algoritmusát írja le. 

g) Ha osztályok, sablonok stb. egy halmazán belül logikai rokonság van, tegyük 
azokat közös névtérbe. 


[2] Ha olyan osztályt hozunk létre, amely nem matematikai egyedet ír le (mint egy 
mátrix vagy komplex szám) vagy nem alacsonyszintű típust (mint egy láncolt lista) 
a) ne használjunk globális adatokat (használjunk tagokat), 
b) ne használjunk globális függvényeket, 
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c) ne használjunk nyilvános adattagokat, 

d) ne használjunk , barát" (friend) függvényeket, kivéve a) vagy c) elkerülésére, 

e) ne tegyünk egy osztályba típusazonosító mezőket, használjunk inkább virtuá- 
lis függvényeket, 

$ ne használjunk helyben kifejtett függvényeket, kivéve ha jelentős optimalizá- 
lásról van szó. 


Egyedi és részletesebb gyakorlati szabályokat az egyes fejezetek , Tanácsok" részében talál- 
hatunk. Emlékeztetjük az olvasót, hogy ezek a tanácsok csak útmutatásul szolgálnak, nem 
megváltoztathatatlan törvények. A tanácsokat csak ott kövessük, ahol értelme van. Nincs 
pótszere az intelligenciának, a tapasztalatnak, a józan észnek és a jó ízlésnek. 


A , soha ne tegyük ezt" alakú szabályokat haszontalannak tekintem. Következésképpen 
a legtöbb tanácsot javaslatként fogalmaztam meg; azt írtam le, mit tegyünk. A , negatív ja- 
vaslatokat" pedig nem úgy kell érteni, mint tiltásokat: nem tudok a C-- olyan fő tulajdon- 
ságáról, melyet ne láttam volna jól felhasználni. A , Tanácsok" nem tartalmaznak magyará- 
Zatokat. Helyette minden tanács mellett hivatkozás található a könyv megfelelő részére. 
Ahol negatív tanács szerepel, a hivatkozott rész rendszerint alternatív javaslatot tartalmaz. 
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Kirándulás a C-t 4 -ban 


, Az első tennivalónk: öljünk 
meg minden törvénytudót" 
(Shakespeare: VI. Henrik, II. 
rész — ford. Németh László) 


Mi a C41-? e Programozási megközelítések e Eljárásközpontú programozás s Modularitás e 
Külön fordítás e Kivételkezelés e Elvont adatábrázolás e Felhasználói típusok s Konkrét 
típusok s Absztrakt típusok e Virtuális függvények s Objektumorientált programozás s Ál- 
talánosított programozás e Tárolók s Algoritmusok s Nyelv és programozás s Tanácsok 


2.1. Mi a C-Ht-? 


A Cs3 általános célú programozási nyelv, melynek fő alkalmazási területe a rendszerprog- 
ramozás és 


egy jobbfajta C, 

támogatja az elvont adatábrázolást, 

támogatja az objektumorientált programozást, valamint 
az általánosított programozást. 


.... 
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Ez a fejezet elmagyarázza, mit jelentenek a fentiek, anélkül, hogy belemenne a nyelv meg- 
határozásának finomabb részleteibe. Célja általános áttekintést adni a C4--ról és használa- 
tának fő módszereiről, nem pedig a Ctt programozás elkezdéséhez szükséges részletes 
információt adni az olvasónak. 


Ha az olvasó túl elnagyoltnak találja e fejezet némelyik részének tárgyalásmódját, egysze- 
rűen ugorja át és lépjen tovább. Később mindenre részletes magyarázatot kap. Mindeneset- 
re, ha átugrik részeket a fejezetben, tegye meg magának azt a szívességet, hogy később 
visszatér rájuk. 


A nyelvi tulajdonságok részletes megértése — még ha a nyelv összes tulajdonságáé is — nem 
ellensúlyozhatja azt, ha hiányzik az átfogó szemléletünk a nyelvről és használatának alap- 
vető módszereiről. 


2.2. Programozási megközelítések 


An 


Az objektumorientált (objektumközpontú) programozás egy programozási mód — a ,jó 
programok írása közben felmerülő sereg probléma megoldásának egy megközelítése (pa- 
radigma). Ha az ,objektumorientált programozási nyelv" szakkifejezés egyáltalán jelent 
valamit, olyan programozási nyelvet kell hogy jelentsen, amely az objektumokat közép- 
pontba helyező programozási stílust támogató eljárásokról gondoskodik. 


Itt fontos megkülönböztetnünk két fogalmat: egy nyelvről akkor mondjuk, hogy támogat 
egy programozási stílust, ha olyan szolgáltatásai vannak, melyek által az adott stílus hasz- 
nálata kényelmes (könnyű, biztonságos és hatékony) lesz. A támogatás hiányzik, ha kivé- 
teles erőfeszítés vagy ügyesség kell az ilyen programok írásához; ekkor a nyelv csupán 
megengedi, hogy az adott megközelítést használjuk. Lehet strukturált programot írni 
Fortran77-ben és objektumközpontút C-ben, de szükségtelenül nehezen, mivel ezek a nyel- 
vek nem támogatják közvetlenül az említett megközelítéseket. 


Az egyes programozási módok támogatása nem csak az adott megközelítés közvetlen hasz- 
nálatát lehetővé tévő nyelvi szolgáltatások magától értetődő formájában rejlik, hanem a for- 
dítási/futási időbeni ellenőrzések finomabb formáiban, melyek védelmet adnak a stílustól 
való akaratlan eltérés ellen. A típusellenőrzés erre a legkézenfekvőbb példa, de a kétértel- 
műség észlelése és a futási idejű ellenőrzések szintén a programozási módok nyelvi támo- 
gatásához tartoznak. A nyelven kívüli szolgáltatások, mint a könyvtárak és programozási 
környezetek, további támogatást adnak az egyes megközelítési módokhoz. 
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Egy nyelv nem szükségszerűen jobb, mint egy másik, csak azért, mert olyan tulajdonságok- 
kal rendelkezik, amelyek a másikban nem találhatók meg. Sok példa van ennek az ellenke- 


zőjére is. A fontos kérdés nem annyira az, milyen tulajdonságai vannak egy nyelvnek, 


hanem inkább az, hogy a meglévő tulajdonságok elegendőek-e a kívánt programozási stí- 
lusok támogatására a kívánt alkalmazási területeken. Ennek kívánalmai a következők: 


1. Minden tulajdonság tisztán és , elegánsan" a nyelv szerves része legyen. 

A tulajdonságokat egymással párosítva is lehessen használni, hogy olyan 

megoldást adjanak, melyhez egyébként külön nyelvi tulajdonságok lennének 

szükségesek. 

A lehető legkevesebb legyen az ál- és , speciális célú" tulajdonság. 

4. Az egyes tulajdonságok megvalósítása nem okozhat jelentős többletterhelést 
olyan programoknál, melyek nem igénylik azokat. 

5. A felhasználónak csak akkor kell tudnia a nyelv valamely részhalmazáról, ha 
kifejezetten használja azt egy program írásához. 


zak 


A fentiek közül az első elv az esztétikához és a logikához való folyamodás. A következő 
kettő a minimalizmus gondolatának kifejezése, az utolsó kettő pedig így összesíthető: , ami- 
ről nem tudunk, az nem fáj". 


A C44-t úgy terveztük, hogy az elvont adatábrázolást, illetve az objektumorientált és az álta- 
lánosított programozást támogassa, mégpedig az e megszorítások mellett támogatott hagyo- 
mányos C programozási módszereken kívül. Nem arra szolgál, hogy minden felhasználóra 
egyetlen programozási stílust kényszerítsen. 


A következőkben néhány programozási stílust és az azokat támogató főbb tulajdonságokat 
vesszük számba. A bemutatás egy sor programozási eljárással folytatódik, melyek az eljárás- 
központú (procedurális) programozástól elvezetnek az objektumorientált programozásban 
használt osztályhierarchiáig és a sablonokat használó általánosított (generikus) programo- 
zásig. Minden megközelítés az elődjére épül, mindegyik hozzátesz valamit a C-t progra- 
mozók eszköztárához, és mindegyik egy bevált tervezési módot tükröz. 


A nyelvi tulajdonságok bemutatása nem teljes. A hangsúly a tervezési megközelítéseken és 
a programok szerkezeti felépítésén van, nem a nyelvi részleteken. Ezen a szinten sokkal 
fontosabb, hogy fogalmat kapjunk arról, mit lehet megtenni C-t4-t használva, mint hogy 
megértsük, hogyan. 
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2.3. Eljárásközpontú programozás 


Az eredeti programozási alapelv a következő: 





Döntsd el, mely eljárásokra van szükséged 
és használd azokhoz a lehető legjobb algoritmusokat. 








A középpontban az eljárás áll — a kívánt számításhoz szükséges algoritmus. A nyelvek ezt 
az alapelvet függvényparaméterek átadásával és a függvények által visszaadott értékekkel 
támogatják. Az e gondolkodásmóddal kapcsolatos irodalom tele van a paraméterátadás és 
a különböző paraméterfajták megkülönböztetési módjainak (eljárások, rutinok, makrók 
stb.) tárgyalásával. 


A jó stílus? jellegzetes példája az alábbi négyzetgyök-függvény. Átadva egy kétszeres pon- 
tosságú lebegőpontos paramétert, a függvény visszaadja az eredményt. Ezt egy jól érthető 
matematikai számítással éri el: 


double sgrt(double arg) 
( 


// a négyzetgyök kiszámításának kódja 


J 


void JO 
( 


double root2 - sgrt(29; 
V/AZOA 


J 


A kapcsos zárójelek a C-4---ban valamilyen csoportba foglalást fejeznek ki; itt a függvény tör- 
zsének kezdetét és a végét jelzik. A kettős törtvonal / egy megjegyzés (commen0) kezdete, 
mely a sor végéig tart. A void kulcsszó jelzi, hogy az ffüggvény nem ad vissza értéket. 


Programszervezési szempontból a függvényeket arra használjuk, hogy rendet teremtsünk 
az eljárások labirintusában. Magukat az algoritmusokat függvényhívásokkal és más nyelvi 
szolgáltatások használatával írjuk meg. A következő alpontok vázlatos képet adnak a Cr 
legalapvetőbb szolgáltatásairól a számítások kifejezéséhez. 
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2.3.1. Változók és aritmetika 
Minden névnek és kifejezésnek típusa van, amely meghatározza a végrehajtható műveleteket: 


int inch; 


A fenti deklaráció például azt adja meg, hogy inch típusa int (vagyis inch egy egész típusú 
változó). 


A deklaráció olyan utasítás, mely a programba egy nevet vezet be. Ehhez a névhez egy tí- 
pust rendel. A típus egy név vagy kifejezés megfelelő használatát határozza meg. 


A C44 több alaptípussal rendelkezik, melyek közvetlen megfelelői bizonyos hardverszol- 
gáltatásoknak. Például: 


bool // logikai típus, lehetséges értékei: true (igaz) és false (hamis) 

char // karakter, például ta, z, vagy 9" 

int // egész érték, például 1, 42, vagy 1216 

double // kétszeres pontosságú lebegőpontos szám, például 3.14 vagy 299793.0 


A char változók természetes mérete egy karakter mérete az adott gépen (rendesen egy 
bájt), az int változóké az adott gépen működő egész típusú aritmetikához igazodik (rend- 
szerint egy gépi szó). 


Az aritmetikai műveletek e típusok bármilyen párosítására használhatók: 


a // összeadás vagy előjel, egy- és kétoberandusú is lehet 
s // kivonás vagy előjel, egy- és kétoberandusú is lehet 

bi // szorzás 

7 // osztás 

96 // maradékképzés 


Ugyanígy az összehasonlító műveletek is: 


sz // egyenlő 

17 // nem egyenlő 

c // kisebb 

- // nagyobb 

s // kisebb vagy egyenlő 
ász // nagyobb vagy egyenlő 


Értékadásokban és aritmetikai műveletekben a C---- az alaptípusok között elvégez minden 
értelmes átalakítást, így azokat egymással tetszés szerint keverhetjük: 
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void some function // értéket vissza nem adó függvény 
( 
double d - 2.2; // lebegőpontos szám kezdeti értékadása 
inti — 7; // egész kezdeti értékadása 
d -— dti; // összeg értékadása 
i - dti; // szorzat értékadása 


Itt -— az értékadó művelet jele és —— az egyenlőséget teszteli, mint a C-ben. 


2.3.2. Elágazások és ciklusok 


A C44 az elágazások és ciklusok kifejezésére rendelkezik a hagyományos utasításkészlet- 
tel. Íme egy egyszerű függvény, mely a felhasználótól választ kér és a választól függő logi- 
kai értéket ad vissza: 


bool acceptO 
( 


cout cz "Do you want to proceed (y or) mt; // kérdés kiírása 


char answer — 0; 
cin 22 answer; // válasz beolvasása 


if (answer —— !) return true; 
return false; 


A cc ( tedd bele") műveleti jelet kimeneti operátorként használtuk; a couta szabványos ki- 
meneti adatfolyam. A 5: ( olvasd be") a bemenet műveleti jele, a cin a szabványos beme- 
nő adatfolyam. A 5: jobb oldalán álló kifejezés határozza meg, milyen bemenet fogadható 
el és ez a beolvasás célpontja. A w karakter a kiírt karakterlánc végén új sort jelent. 


A példa kissé javítható, ha egy n!" választ is számításba veszünk: 
bool accept20 
( 


cout ££ "Do you want to proceed (y or J)) MV; // kérdés kiírása 


char answer — 0; 
cin 22 answer; // válasz beolvasása 
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switch (answer) ( 


case y: 
return true; 
case n: 
return false; 
default: 
cout ca ITII take that for a no Mm"; // nemleges válasznak veszi 
return false; 
, 


A switch utasítás egy értéket ellenőriz, állandók halmazát alapul véve. A case konstansok- 
nak különállóknak kell lenniük, és ha az érték egyikkel sem egyezik, a vezérlés a default 
címkére kerül. A programozónak nem kell alapértelmezésről (defaul9), gondoskodnia. 


Kevés programot írnak ciklusok nélkül. Esetünkben szeretnénk lehetőséget adni a felhasz- 
nálónak néhány próbálkozásra: 


bool accept30 
í 


int tries — 1; 
while (tries £ 4) ( 


cout cz "Do you want to proceed (y or Jn) MV; // kérdés kiírása 
char answer — 0; 
cin 25 answer; // válasz beolvasása 


switch (answer) ( 


case y: 
return true; 
case n: 
return false; 
default: 
cout c£ "Sorry, I dont understand thatNn"; // nem érti a választ 
tries - tries 4 1; 
) 
fi 
cout ca ITII take that for a no Mm";  // nemleges válasznak veszi 
return false; 


J 


A while utasítás addig hajtódik végre, amíg a feltétele hamis nem lesz. 
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2.3.3. Mutatók és tömbök 


Egy tömböt így határozhatunk meg: 


char v[10]; // 10 karakterből álló tömb 
Egy mutatót így: 
char" p; // mutató karakterre 


A deklarációkban a / / jelentése , tömbje" (array of), míg a " jelentése , mutatója" (pointer to). 
Minden tömbnek 0 az alsó határa, tehát v-nek tíz eleme van, 2/07/. . . v/9/. A mutató változó 
a megfelelő típusú objektum címét tartalmazhatja: 


b - kul3]; // p a v negyedik elemére mutat 


A ,címe" jelentéssel bíró operátor az egyoperandusú £. Lássuk, hogyan másolhatjuk át egy 
tömb tíz elemét egy másik tömbbe: 


void another. function 


(t 
int v1(10]; 
int v2[10]; 
H/AKTE 
for (int 1-O; iz10; 441) v1[iJ-v2lij; 


j 


A for utasítás így olvasható: , állítsuk í-t 0-ra, amíg i kisebb, mint 70, az i-edik elemet má- 
soljuk át, és növeljük meg í-t". Ha egész típusú változóra alkalmazzuk, a $-t növelő műve- 
leti jel az értéket egyszerűen eggyel növeli. 


2.4. Moduláris programozás 


Az évek során a programtervezés súlypontja az eljárások felől az adatszervezés irányába to- 
lódott el. Egyebek mellett ez a programok nagyobb méretében tükröződik. Az egymással 
rokon eljárásokat az általuk kezelt adatokkal együtt gyakran modul-nak nevezzük. A meg- 
közelítés alapelve ez lesz: 
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Döntsd el, mely modulokra van szükség és oszd fel 
a programot úgy, hogy az adatokat modulokba helyezed. 











Ez az adatrejtés elve. Ahol az eljárások nincsenek az adatokkal egy csoportban, az eljárás- 
központú programozás megfelel a célnak. Az egyes modulokon belüli eljárásokra a ,jó el- 
járások" tervezésének módja is alkalmazható. A modulra a legközönségesebb példa egy 
verermn (stack) létrehozása. A megoldandó fő problémák: 
1. Gondoskodni kell a verem felhasználói felületéről (pl. busnO és popO 
függvények). 
2. Biztosítani kell, hogy a verem megjelenítése (pl. az elemek tömbje) csak ezen 
a felhasználói felületen keresztül legyen hozzáférhető. 
3. Biztosítani kell a verem első használat előtti előkészítését Cinicializálását). 


A C44 egymással rokon adatok, függvények stb. különálló névterekbe való csoportosításá- 
ra ad lehetőséget. Egy Szack modul felhasználói felülete például így adható meg és használ- 
ható: 


namespace Stack ( // felület 
void push(char); 
char popO; 

9 


void fO 
í 


Stack::pushC c); 
if (Stack::bopO !- tc) error( lehetetlen"); 
) 


A Stack:: minősítés azt jelzi, hogy a pushO és a bopO a Stack névtérhez tartoznak. E nevek 


máshol történő használata nem lesz befolyással erre a programrészre és nem fog Zavart 
okozni. 


A Stack kifejtése lehet a program külön fordítható része: 


namespace Stack ( // megvalósítás 
const int max size - 200; 
char ulmax sizel; 
int top — O; 
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void push(char c) f /? túlcsordulás ellenőrzése és c behelyezése "/ ) 


char bopO ( /? alulcsordulás ellenőrzése és a legfelső elem kiemelése "/ ) 


j 


A Stack modul fontos jellemzője, hogy a felhasználói kódot a Szack::bushO-t és 
a Stack::popO-ot megvalósító kód elszigeteli a Stack adatábrázolásától. A felhasználónak 
nem kell tudnia, hogy a verem egy tömbbel van megvalósítva, a megvalósítás pedig anél- 
kül módosítható, hogy hatással lenne a felhasználói kódra. 


Mivel az adat csak egyike az , elrejtendő" dolgoknak, az adatrejtés elve az információrejtés 
elvévé terjeszthető ki; vagyis a függvények, típusok stb. nevei szintén modulba helyezhe- 
tők. Következésképpen a C-t bármilyen deklaráció elhelyezését megengedi egy névtérben 


(48.2.). 


A fenti Stack modul a verem egy ábrázolásmódja. A következőkben többféle vermet hasz- 
nálunk a különböző programozói stílusok szemléltetésére. 


2.4.1. Külön fordítás 


A Ct4 támogatja a C külön fordítási elvét. Ezt arra használhatjuk, hogy egy programot rész- 
ben független részekre bontsunk. 


Azokat a deklarációkat, melyek egy modul felületét írják le, jellemzően egy fájlba írjuk, 
melynek neve a használatot tükrözi. Ennek következtében a 


namespace Stack ( // felület 
void push(char); 
char popO; 


j 


a stack.h nevű fájlba kerül, a felhasználók pedig ezt az úgynevezett fejállományt (header) 
beépítik (include): 

include "stack.h" // a felület beépítése 

void fO 

j Stack::pushCc)); 


if (Stack::popO !- (c) errorCimpossible"); 
2 


ak 
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Ahhoz, hogy a fordítónak segítsünk az egységesség és következetesség biztosításában, 
a Stack modult megvalósító fájl szintén tartalmazza a felületet: 


jinclude "stack.h" // a felület beépítése 


namespace Stack ( // ábrázolás 
const int max size — 200; 
char vulmax sizel; 
int top — 0; 


J 


void Stack::push(char c) f /? túlcsordulás ellenőrzése és c behelyezése "/ ) 


char Stack::bopO ( /? alulcsordulás ellenőrzése és a legfelső elem kiemelése "/ ) 


A felhasználói kód egy harmadik fájlba kerül (wser.O. A user.c és a stack.c fájlokban lévő 
kód közösen használja a stack.h-ban megadott veremfelületet, de a két fájl egyébként füg- 
getlen és külön-külön lefordítható. A program részei a következőképpen ábrázolhatók: 


stack.h: 











veremfelület 











user. c: stack.c: 








$include "stack.h" 
verem megvalósítása 


include "stack.h" 
verem használata 














A külön fordítás követelmény minden valódi (tényleges használatra szán?) program eseté- 
ben, nem csak a moduláris felépítésűeknél (mint pl. a Stack). Pontosabban, a külön fordí- 
tás használata nem nyelvi követelmény; inkább annak módja, hogyan lehet egy adott nyelvi 
megvalósítás előnyeit a legjobban kihasználni. A legjobb, ha a modularitást a lehető legna- 
gyobb mértékig fokozzuk, nyelvi tulajdonságok által ábrázoljuk, majd külön-külön hatéko- 
nyan fordítható fájlokon keresztül valósítjuk meg (8. és 9. fejeze). 
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2.4.2. Kivételkezelés 


Ha egy programot modulokra bontunk, a hibakezelést a modulok szintjén kell elvégez- 
nünk. A kérdés, melyik modul felelős az adott hiba kezeléséért? A hibát észlelő modul 
gyakran nem tudja, mit kell tennie. A helyreállítási tevékenység a műveletet kezdeménye- 
ző modultól függ, nem attól, amelyik észlelte a hibát, miközben megkísérelte a művelet 
végrehajtását. A programok növekedésével — különösen kiterjedt könyvtárhasználat ese- 
tén — a hibák (vagy általánosabban: a , kivételes események") kezelési szabványai egyre 
fontosabbá válnak. 


Vegyük megint a Stack példát. Mit kell tennünk, amikor túl sok karaktert próbálunk pbushO- 
sal egy verembe rakni? A verem modul írója nem tudja, hogy a felhasználó mit akar tenni 
ilyen esetben, a felhasználó pedig nem mindig észleli a hibát (ha így lenne, a túlcsordulás 
nem történne meg). A megoldás: a Stack írója kell, hogy tudatában legyen a túlcsordulás 
veszélyének és ezután az (ismeretlen) felhasználóval tudatnia kell ezt. A felhasználó majd 
megteszi a megfelelő lépést: 


namespace Stack ( // felület 
void push(char); 
char popO; 
class Overflow f ); // túlcsordulást ábrázoló típus 


J 


Túlcsordulás észlelésekor a Szack::PushO meghívhat egy kivételkezelő kódot; vagyis ,egy 
Overflow kivételt dobhat": 


void Stack::push(char c) 
( 
if (top -- max size) throw OverflowO; 
// c behelyezése 
j 
A throw a vezérlést a Stack:: Overflowtípusú kivételkezelőnek adja át, valamilyen függvény- 
ben, mely közvetve vagy közvetlenül meghívta a Srack::PushO-t. Ehhez , visszatekerjük" 
a függvényhívási vermet, ami ahhoz szükséges, hogy visszajussunk a hívó függvény kör- 
nyezetéhez. Így a throw úgy működik, mint egy többszintű return. Például: 


void JO 
( 
ML -86 
try f // a kivételekkel az alább meghatározott kezelő foglalkozik 
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while (true) Stack::push(C c; 


catch (Stack:: Overflow) f 
// hoppá: verem-tűlcsordulás; a megfelelő művelet végrehajtása 


f 
7443 


J 


A while ciklus örökké ismétlődne, ezért ha valamelyik Stack::pushO hívás egy throw-t vált 
ki, a vezérlés a Stack:: Overflow-t kezelő catch részhez kerül. 


A kivételkezelő eljárások használata szabályosabbá és olvashatóbbá teheti a hibakezelő kó- 
dot. További tárgyalás, részletek és példák: §8.3, 14. fejezet, ,E" függelék. 


2.5. Elvont adatábrázolás 


A modularitás alapvető szempont minden sikeres nagy programnál. E könyv minden terve- 
zési vizsgálatában ez marad a középpontban. Az előzőekben leírt alakú modulok azonban 
nem elegendőek ahhoz, hogy tisztán kifejezzünk összetett rendszereket. Az alábbiakban 
a modulok használatának egyik módjával foglalkozunk (felhasználói típusok létrehozása), 
majd megmutatjuk, hogyan küzdjünk le problémákat a felhasználói típusok közvetlen lét- 
rehozása révén. 


2.5.1. Típusokat leíró modulok 


A modulokkal való programozás elvezet az összes azonos típusú adatnak egyetlen típuske- 
zelő modul általi központosított kezeléséhez. Ha például sok vermet akarunk -— az előbbi 
Stack modulban található egyetlen helyett — megadhatunk egy veremkezelőt, az alábbi fe- 
lülettel: 


namespace Stack f 
struct Rep; // a verem szerkezetének meghatározása máshol található 
typedef Repk stack; 


stack createO; // új verem létrehozása 
void destroy(stack 5); // s törlése 
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void push(stack s, char c); // c behelyezése az s verembe 


char pop(stack 5); // s legfelső elemének kiemelése 


j 


A következő deklaráció azt mondja, hogy Rep egy típus neve, de későbbre hagyja a típus 
meghatározását (45.79. 


struct Rep; 
Az alábbi deklaráció a szack nevet adja egy , Rep referenciának" (részletek §5.5-ben). 


typedef Repg stack; 


Az ötlet az, hogy a vermet saját Stack::stack-jével azonosítjuk és a további részleteket a fel- 
használó elől elrejtjük. A Szack::stack működése nagyon hasonlít egy beépített típuséhoz: 


struct Bad bop ( 3); 


void JO 

( 
Stack::stack 51 — Stack::createO; // új verem létrehozása 
Stack::stack 52 - Stack::createO); // még egy verem létrehozása 


Stack::push(s1, c); 
Stack::push(s2, k)); 


if (Stack::pop(s1) !- c) throw Bad popO; 
if (Stack::pop(s2) !- kk) throw Bad popO; 


Stack::destroy(s 1; 
Stack::destroy(s29; 


Ezt a Stack-et többféleképpen megvalósíthatnánk. Fontos, hogy a felhasználónak nem 
szükséges tudnia, hogyan tesszük ezt. Amíg a felületet változatlanul hagyjuk, a felhasználó 
nem fogja észrevenni, ha úgy döntünk, hogy átírjuk a Stack-et. Egy megvalósítás például 
előre lefoglalhatna néhány verempéldányt és a Szack::create0) egy nem használt példányra 
való hivatkozást adna át. Ezután a Stack::destroyO egy ábrázolást , nem használt"-ként jelöl- 
het meg, így a Stack::createO újra használhatja azt: 


namespace Stack ( // ábrázolás 


const int max size - 200; 
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struct Rep f 
char ulmax sizel; 


int top; 
); 
const int max -— 16; // vermek maximális száma 
Rep stacks(lmax[]; // előre lefoglalt verempéldányok 
bool usedlmaxi; // usedli] igaz, ha stacksl[lil használatban van 


typedef Repf stack; 
J 


void Stack::push(stack s, char c) ( / s tűlcsordulásának ellenőrzése és c behelyezése "/ ) 
char Stack::bop(stack 5) ( /" s alulcsordulásának ellenőrzése és a legfelső elem kiemelése "/ ) 


Stack::stack Stack::createO) 


( 
// használaton kívüli Rep kiválasztása, használtként 
// megjelölése, előkészítése, rá mutató hivatkozás visszaadása 


J 


void Stack::destroy(stack 5) ( /: s megjelölése nem használtként "/ ) 


Amit tettünk, az ábrázoló típus becsomagolása felületi függvények készletébe. Az, hogy az 
eredményül kapott , stack típus" hogyan viselkedik, részben attól függ, hogyan adtuk meg 
ezeket a felületi függvényeket, részben attól, hogyan mutattuk be a Szack-et ábrázoló típust 
a verem felhasználóinak, részben pedig magától az ábrázoló típustól. 


Ez gyakran kevesebb az ideálisnál. Jelentős probléma, hogy az ilyen ,műtípusoknak?" a fel- 
használók részére való bemutatása az ábrázoló típus részleteitől függően nagyon változó le- 
het — a felhasználókat viszont el kell szigetelni az ábrázoló típus ismeretétől. Ha például egy 
jobban kidolgozott adatszerkezetet választottunk volna a verem azonosítására, 
a Stack::stack-ek értékadási és előkészítési (inicializálási) szabályai dc$ámai módon megvál- 
toztak volna (ami néha valóban kívánatos lehe). Ez azonban azt mutatja, hogy a kényel- 
mes vermek szolgáltatásának problémáját egyszerűen áttettük a Stack modulból 
a Stack::stack ábrázoló típusba. 


Még lényegesebb, hogy azok a felhasználói típusok, melyeket az adott megvalósító típus- 
hoz hozzáférést adó modul határozott meg, nem úgy viselkednek, mint a beépített típusok, 
és kisebb vagy más támogatást élveznek, mint azok. Azt például, hogy mikor használható 
egy Stack::Rep, a Stack::createO) és a Stack::destroyO függvény ellenőrzi, nem a szokásos 
nyelvi szabályok. 
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2.5.2. Felhasználói típusok 


A C44 ezt a problémát úgy küzdi le, hogy engedi, hogy a felhasználó közvetlenül adjon 
meg típusokat, melyek közel úgy viselkednek, mint a beépített típusok. Az ilyen típusokat 
gyakran elvont vagy absztrakt adattípusoknak (abstract data type, ADT) nevezzük. A szer- 
ző inkább a felhasználói típus (user-defined type) megnevezést kedveli. Az elvont adattí- 
pus kifejezőbb meghatározásához , absztrakt" matematikai leírás kellene. Ha adva volna 
ilyen, azok, amiket itt típusoknak nevezünk, az ilyen valóban elvont egyedek konkrét pél- 
dányai lennének. A programozási megközelítés most ez lesz: 





Döntsd el, mely típusokra van szükség 
és mindegyikhez biztosíts teljes műveletkészletet. 











Ott, ahol egy típusból egy példánynál többre nincs szükség, elegendő a modulokat haszná- 
ló adatrejtési stílus. Az olyan aritmetikai típusok, mint a racionális és komplex számok, kö- 
zönséges példái a felhasználói típusnak. Vegyük az alábbi kódot: 


class complex f 
double re, im; 


bublic: 
complex(double r, double i) f re-r; im-i; ) // complex létrehozása két skalárból 
complex(double r) f re-r; im-0O; ) // complex létrehozása egy skalárból 
complexO f re - im - O; ) // alapértelmezett complex: (O,0) 
friend complex operatort (complex, complex); 
friend complex operator-(complex, complex); // kétoberandusú 
friend complex operator-(complex); // egyoberandusú 


friend complex operator" (complex, complex); 
friend complex operator((complex, complex); 


friend bool operator--(complex, complex); // egyenlő 
friend bool operator!1-(complex, complex); // nem egyenlő 
Ms 


J; 


A complex osztály (vagyis felhasználói típus) deklarációja egy komplex számot és a rajta 
végrehajtható műveletek halmazát ábrázolja. Az ábrázolás privát (private); vagyis a re és az 
im csak a complex osztály bevezetésekor megadott függvények által hozzáférhető. Ezeket 


az alábbi módon adhatjuk meg: 
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complex operatort(complex a1, complex a2) 


( 


return complex(a1.ret4a2.re,a1.imi4-a2.im); 


J 


Az a tagfüggvény, melynek neve megegyezik az osztályéval, a konstruktor. A konstruktor 
írja le az osztály egy objektumának előkészítési-létrehozási módját. A complex osztály 
három konstruktort tartalmaz. Egyikük egy double-ból csinál complex-et, egy másik egy 
double párból, a harmadik alapértelmezett érték alapján. A complex osztály így hasz- 
nálható: 


void (complex 2) 
f 
complex a - 2.3; 
complex b - 1/a; 
complex c - a4b"complex(1, 2.3); 
Z9gak 
if (c !- D) c - -(b/a)a27b; 


A fordító a komplex számokhoz kapcsolt műveleti jeleket megfelelő függvényhívásokká 
alakítja. A c/-b jelentése például operator/-(c, b), az 1/a jelentése opberator/ (complex(1 ), a). 
A legtöbb — de nem minden — modul jobban kifejezhető felhasználói típusként. 


2.5.3. Konkrét típusok 


Felhasználói típusok változatos igények kielégítésére készíthetők. Vegyünk egy felhaszná- 
lói veremtípust a complex típus soraival együtt. Ahhoz, hogy kissé valósághűbbé tegyük 
a példát, ez a Stack típus paraméterként elemei számát kapja meg: 


class Stack ( 


char? u; 
int top; 
int max Size; 

bublic: 
class Underflow f ; ; // kivétel 
class Overflow f ); // kivétel 
class Bad size ( ); // kivétel 
StackCint 5); // konstruktor 


-StackO; // destruktor 
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void push(char c); 
char popO; 
s 


Aa 


A Stack(int) konstruktor meghívódik, valahányszor létrehozzuk az osztály egy példányát. 
Ez a függvény gondoskodik a kezdeti értékadásról. Ha bármilyen , takarításra" van szükség, 
amikor az osztály egy objektuma kikerül a hatókörből, megadhatjuk a konstruktor ellenté- 
tét, a destruktort: 


Stack::Stack(int s)  // konstruktor 


( 
top — 0; 
if (s2o II 10000£-£5) throw Bad sizeO; / "11" jelentése "vagy" 
max size — s; 
v - new charlsl; . / az elemek szabad tárba helyezése 
J 
Stack::-StackO // destruktor 


( 


delete[ ] v; // elemek törlése, hely felszabadítása újrafelhasználás céljára (§6.2.6) 


J 


A konstruktor egy új Szack változót hoz létre. Ehhez lefoglal némi helyet a szabad tárból 
(heap - halom, kupac - vagy dinamikus tár) a new operátor használatával. A destruktor ta- 
karít, felszabadítva a tárat. Az egész a Stack-ek felhasználóinak beavatkozása nélkül törté- 
nik. A felhasználók a vermeket ugyanúgy hozzák létre és használják, ahogy a beépített tí- 
pusú változókat szokták. Például: 


Stack s var1(109; // 10 elemet tárolni képes globális verem 
void KStackg s ref, int i) // hivatkozás a Stack veremre 
( 

Stack s var2(); // lokális verem i számú elemmel 

Stack" s ptr - new Stack(209; // mutató a szabad tárban levő Stack-re 


s var1.pushCa),; 
s var2.push( b); 
s refpushCc9; 

s plr-CpushCd?; 
Ms 


Ez a Stack típus ugyanolyan névadásra, hatókörre, élettartamra, másolásra stb. vonatkozó 
szabályoknak engedelmeskedik, mint az int vagy a char beépített típusok. 
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Természetszerűen a pushO és popO tagfüggvényeket valahol szintén meg kell adni: 


void Stack::push(char c) 
í 


if (op -- max size) throw OverflowO; 
ultop! — c; 
top - top 4 [; 

J 


char Stack::bpopO 


if (op -- 0) throw UnderflowO; 
top — top - [; 
return ultopl; 


J 


A complex és Stack típusokat konkrét típusnak nevezzük, ellentétben az absztrakt típusok- 
kal, ahol a felület tökéletesebben elszigeteli a felhasználót a megvalósítás részleteitől. 


2.5.4. Absztrakt típusok 


Amikor a Stackrőól, mint egy modul (42.5.1) által megvalósított , műtípusról" áttértünk egy sa- 
ját típusra (42.5.3), egy tulajdonságot elvesztettünk. Az ábrázolás nem válik el a felhaszná- 
lói felülettől, hanem része annak, amit be kellene építeni (include) a vermeket használó 
programrészbe. Az ábrázolás privát, ezért csak a tagfüggvényeken keresztül hozzáférhető, 
de jelen van. Ha bármilyen jelentős változást szenved, a felhasználó újra le kell, hogy for- 
dítsa. Ezt az árat kell fizetni, hogy a konkrét típusok pontosan ugyanúgy viselkedjenek, 
mint a beépítettek. Nevezetesen egy típusból nem lehetnek valódi lokális (helyi) változó- 
ink, ha nem tudjuk a típus ábrázolásának méretét. 


Azon típusoknál, melyek nem változnak gyakran, és ahol lokális változók gondoskodnak 
a szükséges tisztaságról és hatékonyságról, ez elfogadható és gyakran ideális. Ha azonban 
teljesen el akarjuk szigetelni az adott verem felhasználóját a megvalósítás változásaitól, 
a legutolsó Siack nem elegendő. Ekkor a megoldás leválasztani a felületet az ábrázolásról 
és lemondani a valódi lokális változókról. 


Először határozzuk meg a felületet: 


class Stack ( 

bublic: 
class Underflow f ); // kivétel 
class Overflow f ); // kivétel 
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virtual void push(char c) — 0; 
virtual char popO - 0; 


J; 


A virtual szó a Simulában és a C4--ban azt jelenti, hogy ,az adott osztályból származtatott 
osztályban később felülírható". Egy Stack-ből származtatott osztály a Stack felületet valósít- 
ja meg. A furcsa —-0 kifejezés azt mondja, hogy a veremből származtatott osztálynak meg 
kell határoznia a függvényt. Ilyenformán a Stack felületként szolgál bármilyen osztály részé- 


re, mely tartalmazza a bushO és popO függvényeket. Ezt a Szack-et így használhatnánk: 


void KStackk s ref) 
( 
s refipushCc); 
if (s ref.popO !- c) throw Bad popO; 
j 
Vegyük észre, hogyan használja JO a Stack felületet, a megvalósítás mikéntjéről mit sem 
tudva. Az olyan osztályt, mely más osztályoknak felületet ad, gyakran többalakú (polimorf) 
típusnak nevezzük. 


Nem meglepő, hogy a megvalósítás a konkrét Szack osztályból mindent tartalmazhat, amit 
kihagytunk a Stack felületből: 


class Array stack : public Stack ( // Array stack megvalósítja Stack-et 
char? p; 
int max size; 
int top; 
bublic: 
Array stackCGint 5); 
-Array stackO; 


void push(char c); 
char popO; 
2. 


Jo 


A ,:public" olvasható úgy, mint , származtatva ...-ból", , megvalósítja ...-t", vagy , . . .altípusa 
. ..-nak". 


Az JO függvény részére, mely a megvalósítás ismeretének teljes hiányában egy Sracket akar 
használni, valamilyen másik függvény kell létrehozzon egy objektumot, amelyen az /0 mű- 
veletet hajthat végre: 


void gO 
Ti 
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Array stack as(2009; 
JHa59; 
) 


Mivel JÓ nem tud az Array stack-ekről, csak a Stack felületet ismeri, ugyanolyan jól fog mű- 
ködni a Stack egy másik megvalósításával is: 


class List stack : public Stack ( // List stack megvalósítja Stack-et 
listkchar? lc; // (standard könyvtárbeli) karakterlista (§3.7.3) 
bublic: 


List stackO 1 ) 


void push(char c) f lc.push front(c9; ) 


char popO; 

j; 

char List stack::popO 

( 
char x — lc. frontO; // az első elem lekérése 
lc.pop frontO; // az első elem eltávolítása 
return Xx; 

J 


Itt az ábrázolás egy karakterlista. Az /c.Dush front(c) beteszi c-t, mint /c első elemét, az 
lc.pop front hívás eltávolítja az első elemet, az lc.frontO pedig lc első elemére utal. 


Egy függvény létre tud hozni egy List stack-et és /0 használhatja azt: 


void hO 
( 


List stack ls; 
JI; 
3 


2.5.5. Virtuális függvények 


Hogyan történik az /0-en belüli s refpopO hívás feloldása a megfelelő függvénydefiníció 
hívására? Amikor hO-ból hívjuk /0-et, a List stack::bopO-ot kell meghívni, amikor g0-ből, 
az Array stack::bopO-ot. Ahhoz, hogy ezt feloldhassuk, a Srack objektumnak információt 
kell tartalmaznia arról, hogy futási időben mely függvényt kell meghívni. A fordítóknál szo- 
kásos eljárás egy virtuális függvény nevének egy táblázat valamely sorszámértékévé alakí- 
tása, amely táblázat függvényekre hivatkozó mutatókat tartalmaz. A táblázatot , virtuális 
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függvénytáblának" vagy egyszerűen uvtbl-nek szokás nevezni. Minden virtuális függvénye- 
ket tartalmazó osztálynak saját vtbl-je van, mely azonosítja az osztály virtuális függvényeit. 
Ez grafikusan így ábrázolható: 


Array stack objektum: vtbl: Array stack::bushO 
j9— szea átáll TEVÉS EZ EZTET 
max size a Array stack::bopO 





























top 

List stack objektum: tbl: 

ÉR LEE SÉAB jé eze E szea List stack::pushO 
lc 








List stack::bopO 














A utbi-ben lévő függvények lehetővé teszik, hogy az objektumot akkor is helyesen használ- 
juk, ha a hívó nem ismeri annak méretét és adatainak elrendezését. A hívónak mindössze 
a utbl helyét kell tudnia a Szack-en belül, illetve a virtuális függvények sorszámát. Ez a vir- 
tuális hívási eljárás lényegében ugyanolyan hatékonnyá tehető, mint a , normális függvény- 
hívás". Többlet helyszükséglete: a virtuális függvényeket tartalmazó osztály minden objek- 
tumában egy-egy mutató, valamint egy-egy vtbl minden osztályhoz. 


2.6. Objektumorientált programozás 


Az elvont adatábrázolás a jó tervezéshez alapfontosságú, a könyvben pedig a tervezés végig 
központi kérdés marad. A felhasználói típusok azonban önmagukban nem elég rugalmasak 
ahhoz, hogy kiszolgálják igényeinket. E részben először egyszerű felhasználói típusokkal 
mutatunk be egy problémát, majd megmutatjuk, hogyan lehet azt megoldani osztályhierar- 
chiák használatával. 


2.6.1. Problémák a konkrét típusokkal 
A konkrét típusok — a modulokban megadott , műtípusokhoz" hasonlóan -— egyfajta , fekete 


dobozt" írnak le. Ha egy fekete dobozt létrehozunk, az nem lép igazi kölcsönhatásba 
a program többi részével. Nincs mód arra, hogy új felhasználáshoz igazítsuk, kivéve, ha de- 
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finícióját módosítjuk. Ez a helyzet ideális is lehet, de komoly rugalmatlansághoz is vezethet. 
Vegyük például egy grafikus rendszerben használni kívánt Shape (Alakzat) típus meghatá- 
rozását. Tegyük fel, hogy pillanatnyilag a rendszernek köröket, háromszögeket és négyze- 
teket kell támogatnia. Tegyük fel azt is, hogy léteznek az alábbiak: 


class Point £/5 ... "7 ); 
class Color £/£ ... "7 ); 


A / és "/ egy megjegyzés kezdetét, illetve végét jelöli. A jelölés többsoros megjegyzések- 
hez is használható. 


Egy alakzatot az alábbi módon adhatunk meg: 


enum Kind f circle, triangle, sguare ; ; // felsorolás (§4.8) 


class Shape f 
Kind k; // típusmező 
Point center; 
Color col; 


V/4 


bublic: 
void drawO; 
void rotate(int); 
MI... 

Vö 


A ktípusazonosító mező azért szükséges, hogy az olyan műveletek számára, mint a drawO 
(rajzolás) vagy a rotate0 (forgatás) meghatározhatóvá tegyük, milyen fajta alakzattal van 
dolguk. (A Pascal-szerű nyelvekben egy változó rekordtípust használhatnánk, k címkével). 
A drau0l függvényt így adhatnánk meg: 


void Shape::drawO 


switch (Rk) ( 

case circle: 
// kör rajzolása 
break; 


case triangle: 
// háromszög rajzolása 
break; 
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case sguagre: 
// négyzet rajzolása 
break; 


Ez azonban , rendetlenség". A függvényeknek -— mint a drawO - tudniuk kell arról, milyen 
alakzatfajták léteznek. Ezért az ilyen függvénynél mindig növekszik a kód, valahányszor 
a rendszerhez egy új alakzatot adunk. Ha új alakzatot hozunk létre, minden műveletet meg 
kell vizsgálni és (ehetőség szerint) módosítani kell azokat. A rendszerhez nem adhatunk új 
alakzatot, hacsak hozzá nem férünk minden művelet forráskódjához. Mivel egy új alakzat 
hozzáadása magával vonja minden fontos alakzat-művelet kódjának módosítását, az ilyen 
munka nagy ügyességet kíván és hibákat vihet be a más (régebbi) alakzatokat kezelő kód- 
ba. Az egyes alakzat-ábrázolások kiválasztását komolyan megbéníthatja az a követelmény, 
hogy az ábrázolásoknak (egalább is néhánynak) illeszkednie kell abba a - jellemzően rög- 
zített méretű — keretbe, melyet az általános Shape típus leírása képvisel. 


2.6.2. Osztályhierarchiák 


A probléma az, hogy nincs megkülönböztetés az egyes alakzatok általános tulajdonságai 
(szín, rajzolhatóság stb.) és egy adott alakzatfajta tulajdonságai közt. (A kör például olyan 
alakzat, melynek sugara van, egy körrajzoló függvénnyel lehet megrajzolni stb.). E megkü- 
lönböztetés kifejezése és előnyeinek kihasználása az objektumorientált programozás lénye- 
ge. Azok a nyelvek, melyek e megkülönböztetés kifejezését és használatát lehetővé tévő 
szerkezetekkel rendelkeznek, támogatják az objektumközpontúságot, más nyelvek nem. 
A megoldásról a Simulából kölcsönzött öröklés gondoskodik. Először létrehozunk egy osz- 
tályt, mely minden alakzat általános tulajdonságait leírja: 


class Shape ( 
Point center; 
Color col; 
ges 
bublic: 
Point whereO f return center; ) 
void move( Point to) f center — to; / ... §/ drawO,; ) 


virtual void drawO — 0; 
virtual void rotate(int angle) - O; 


ES 


Jo 
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Akárcsak a §2.5.4 absztrakt Stack típusában, azokat a függvényeket, melyeknél a hívási 
felület meghatározható, de a konkrét megvalósítás még nem ismert, virtuálisként 
(virtua)D) vezetjük be. 


A fenti meghatározás alapján már írhatunk általános függvényeket, melyek alakzatokra hi- 
vatkozó mutatókból álló vektorokat kezelnek: 


void rotate allívectorsShapet:-k v, int angle)  // v elemeinek elforgatása angle szöggel 


í 
for Gnt i - O; izv.sizeO; 441) ulij-2xrotatecangle); 


J 


Egy konkrét alakzat meghatározásához meg kell mondanunk, hogy alakzatról van szó és 
meg kell határoznunk konkrét tulajdonságait (beleértve a virtuális függvényeket is): 


class Circle : public Shape f 

int radius; 
bublic: 

void drawO f /: ... "/) 

void rotate(Gin0) (? // igen, üres függvény 
Ja 


A C44-ban a Circle osztályról azt mondjuk, hogy a Shape osztályból származik (derived), 
a Shape osztályról pedig azt, hogy a Circle osztály őse ill. bázisosztálya (alaposztálya, base). 
Más szóhasználat szerint a Circle és a Shape alosztály (subclass), illetve főosztály (superclass). 
A származtatott osztályról azt mondjuk, hogy örökli (inherit) a bázisosztály tagjait, ezért 
a bázis- és származtatott osztályok használatát általában öröklésként említjük.A programozási 
megközelítés itt a következő: 





Döntsd el, mely osztályokra van szükséged, 
biztosíts mindegyikhez teljes műveletkészletet, 
az öröklés segítségével pedig határold körül pontosan 
a közös tulajdonságokat. 











Ahol nincs ilyen közös tulajdonság, elegendő az elvont adatábrázolás. A típusok közti, 
öröklés és virtuális függvények használatával kiaknázható közösség mértéke mutatja, 
mennyire alkalmazható egy problémára az objektumorientált megközelítés. Némely terüle- 
ten, például az interaktív grafikában, világos, hogy az objektumközpontúságnak óriási le- 
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hetőségei vannak. Más területeken, mint a klasszikus aritmetikai típusoknál és az azokon 
alapuló számításoknál, alig látszik több lehetőség, mint az elvont adatábrázolás, így az ob- 
jektumközpontúság támogatásához szükséges szolgáltatások feleslegesnek tűnnek. 


Az egyes típusok közös tulajdonságait megtalálni nem egyszerű. A kihasználható közösség 
mértékét befolyásolja a rendszer tervezési módja. Amikor egy rendszert tervezünk — és ak- 
kor is, amikor a rendszerkövetelményeket leírjuk — aktívan kell keresnünk a közös tulajdon- 
ságokat. Osztályokat lehet kifejezetten más típusok építőkockáiként tervezni, a létező osz- 
tályokat pedig meg lehet vizsgálni, mutatnak-e olyan hasonlóságokat, amelyeket egy közös 
bázisosztályban kihasználhatnánk. Az objektumorientált programozás konkrét programo- 
zási nyelvi szerkezetek nélkül való elemzésére irányuló kísérleteket lásd [Kerr,1987] és 
[Booch, 1994] a §23.6-ban. 


Az osztályhierarchiák és az absztrakt osztályok (42.5.4) nem kölcsönösen kizárják, hanem 
kiegészítik egymást (412.5), így az itt felsorolt irányelvek is inkább egymást kiegészítő, köl- 
csönösen támogató jellegűek. Az osztályok és modulok például függvényeket tartalmaz- 
nak, míg a modulok osztályokat és függvényeket. A tapasztalt tervező sokféle megközelí- 
tést használ — ahogy a szükség parancsolja. 


2.7. Általánosított programozás 


Ha valakinek egy verem kell, nem feltétlenül karaktereket tartalmazó veremre van szüksé- 
ge. A verem általános fogalom, független a karakter fogalmától. Következésképpen függet- 
lenül kell ábrázolni is. 


Még általánosabban, ha egy algoritmus az ábrázolástól függetlenül és logikai torzulás nél- 
kül kifejezhető, akkor így is kell tenni. A programozási irányelv a következő: 





Döntsd el, mely algoritmusokra van szükség, 
és úgy lásd el azokat paraméterekkel, hogy minél több típussal 
és adatszerkezettel működjenek. 











2.7.1. Tárolók 


Egy karakterverem-típust általánosíthatunk, ha sablont (template) hozunk létre belőle és 
a konkrét char típus helyett sablonparamétert használunk. Például: 
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templatexclass T- class Stack f 
Tt u; 
int max Size; 
int top; 
bublic: 
class Underflow f ?); 
class Overflow f ); 


StackCint 5); // konstruktor 
-StackO; // destruktor 
void pbush( D; 
T popO; 

Hz 


A templatecciass T- előtag T-t az utána következő deklaráció paraméterévé teszi. 
Hasonlóképpen adhatjuk meg a tagfüggvényeket is: 


templatexcilass T: void StackcT:::bush(T c) 
( 


if (op -- max size) throw OverflowO; 
ultop! — c; 
top - top t [; 

J 


templatexclass T- T StackcT:::bopO 


( 
if (top -- 0) throw UnderflowO; 


top — top - [; 
return ultopl; 


J 


Ha a definíciók adottak, a vermet az alábbi módon használhatjuk: 


Stackcchar: sc(200); // verem 200 karakter számára 
Stackccomplex? scpix(309; // verem 30 komplex szám részére 
Stackc listsint: 5 sli(45); // verem 45, egészekből álló lista számára 
void JO 
f 

sc.push(C c; 


if (sc.popO !/- tc) throw Bad popO; 


scplx.push(complex(1,2)9; 
if (scplx.popO !- complex(1,2)) throw Bad popO; 
J 
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Hasonló módon, sablonokként adhatunk meg listákat, vektorokat, asszociatív tömböket 
(map) és így tovább. Az olyan osztályt, amely valamilyen típusú elemek gyűjteményét tar- 
talmazza, általában container class-nak vagy egyszerűen tárolónak (konténernek) hívjuk. 


A sablonoknak fordítási időben van jelentőségük, tehát használatuk a , kézzel írott" kódhoz 
képest nem növeli a futási időt. 


2.7.2. Általánosított algoritmusok 


A C4- standard könyvtára többféle tárolóról gondoskodik, de a felhasználók sajátokat is 
írhatnak (3., 17. és 18. fejezetek). Ismét használhatjuk tehát az általánosított (generikus) 
programozás irányelveit algoritmusok tárolók általi paraméterezésére. Tegyük fel, hogy 
vektorokat, listákat és tömböket akarunk rendezni, másolni és átkutatni, anélkül, hogy min- 
den egyes tárolóra megírnánk a sortO, copyO és searchO függvényeket. Konvertálni nem 
akarunk egyetlen adott adatszerkezetre sem, melyet egy konkrét sort függvény elfogad, 
ezért találnunk kell egy általános módot a tárolók leírására, mégpedig olyat, amely megen- 
gedi, hogy egy tárolót anélkül használjunk, hogy pontosan tudnánk, milyen fajta tárolóról 
van szó. 


Az egyik megoldás, amelyet a C$- standard könyvtárában a tárolók és nem numerikus al- 
goritmusok megközelítéséből (18. fej. §3.8) vettünk át, a sorozatokra összpontosít és azo- 


kat bejárókkal ( iterator) kezeli. 


Íme a sorozat fogalmának grafikus ábrázolása: 


Kezdet Vég 





— — — —y ! ; 
elemek: ge : 


A sorozatnak van egy kezdete és egy vége. A bejáró (iterator) valamely elemre hivatkozik 
és gondoskodik arról a műveletről, melynek hatására legközelebb a sorozat soron követke- 
ző elemére fog hivatkozni. A sorozat vége ugyancsak egy bejáró, mely a sorozat utolsó ele- 
mén túlra hivatkozik. A , vége" fizikai ábrázolása lehet egy , őr" (sentineD elem, de elkép- 
zelhető más is. A lényeg, hogy a sorozat számos módon ábrázolható, így listákkal és töm- 
bökkel is. 
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Az olyan műveletekhez, mint , egy bejáró által férjünk hozzá egy elemhez" és, a bejáró hi- 
vatkozzon a következő elemre" szükségünk van valamilyen szabványos jelölésre. Ha az 
alapötletet megértettük, az első helyén kézenfekvő választás a " dereferencia (hivatkozó 
vagy mutató) operátort használni, a másodiknál pedig a 4-4 növelő műveleti jelet. 


A fentieket adottnak tekintve, az alábbi módon írhatunk kódot: 


templatecciass In, class Out: void copy(in from, In too far, Out to) 


( 
while (from !- too far) f 
sto — tfrom; // hivatkozott elemek másolása 
4-0; // következő cél 
t4from; // következő forrás 
) 
J 


Ez átmásol bármilyen tárolót, amelyre a formai követelmények betartásával bejárót adhatunk 
meg. A C4-4 beépített, alacsonyszintű tömb és mutató típusai rendelkeznek a megfelelő mű- 
veletekkel: 


char vc1(200]; // 200 karakter tömbje 
char vc2[500]; // 500 karakter tömbje 
void JO 


copy(k vc1[(0/,kvc1l(200/ kvc2OD; 
37 


Ez vc1-et első elemétől az utolsóig vc2-be másolja, vc2 első elemétől kezdődően. 


Minden standard könyvtárbeli tároló (17. Fej., §16.3) támogatja ezt a bejáró- (iterator) és so- 
rozatjelölést. A forrás és a cél típusait egyetlen paraméter helyett két sablonparaméter, az In 
és Out jelöli. Ezt azért tesszük, mert gyakran akarunk másolni egy fajta tárolóból egy másik 
fajtába. Például: 


complex ac[200/; 


void g(vectorccomplexzdk vc, listccomplex:k lc) 
( 
copy(k ac[0/,£ ac[200/, lc.beginO ); 
copy(Ic.beginO, lc.endO, vc.beginO); 
J 
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Itt a tömböt a /ist-be másoljuk, a list-et pedig a vector-ba. Egy szabványos tárolónál a beginŐ 
a bejáró (iterator), amely az első elemre mutat. 


2.8. Utóirat 


Egyetlen programozási nyelv sem tökéletes. Szerencsére egy programozási nyelvnek nem 
kell tökéletesnek lennie ahhoz, hogy jó eszközként szolgáljon nagyszerű rendszerek építé- 
séhez. Valójában egy általános célú programozási nyelv nem is lehet minden feladatra tö- 
kéletes, amire csak használják. Ami egy feladatra tökéletes, gyakran komoly fogyatékossá- 
gokat mutathat egy másiknál, mivel az egy területen való tökéletesség magával vonja 
a szakosodást. A C----t ezért úgy terveztük, hogy jó építőeszköz legyen a rendszerek széles 
választékához és a fogalmak széles körét közvetlenül kifejezhessük vele. 


Nem mindent lehet közvetlenül kifejezni egy nyelv beépített tulajdonságait felhasználva. 
Valójában ez nem is lenne ideális. A nyelvi tulajdonságok egy sereg programozási stílus és 
módszer támogatására valók. Következésképpen egy nyelv megtanulásánál a feladat 
a nyelv sajátos és természetes stílusainak elsajátítására való összpontosítás, nem az összes 
nyelvi tulajdonság minden részletre kiterjedő megértése. 


A gyakorlati programozásnál kevés az előnye, ha ismerjük a legrejtettebb nyelvi tulajdon- 
ságokat vagy ha a legtöbb tulajdonságot kihasználjuk. Egyetlen nyelvi tulajdonság önmagá- 
ban nem túl érdekes. Csak akkor lesz jelentékeny, ha az egyes programozási módszerek és 
más tulajdonságok környezetében tekintjük. Amikor tehát az Olvasó a következő fejezete- 
ket olvassa, kérjük, emlékezzen arra, hogy a C-t részletekbe menő vizsgálatának igazi cél- 
ja az, hogy képesek legyünk együttesen használni a nyelv szolgáltatásait, jó programozási 
stílusban, egészséges tervezési környezetben. 


2.9. Tanácsok 


[II Ne essünk kétségbe! Idővel minden kitisztul. §2.1. 
[2] Jó programok írásához nem kell ismernünk a C-4- minden részletét. §1.7. 
[3] A programozási módszerekre összpontosítsunk, ne a nyelvi tulajdonságokra. §2.1. 
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, Minek vesztegessük az időt tanulásra, 
mikor a tudatlanság azonnali?" 
(Hobbes) 


Szabványos könyvtárak e Kimenet e Karakterláncok e" Bemenet s Vektorok e Tartomány- 
ellenőrzés e Listák 9 Asszociatív tömbök s Tárolók (áttekintés) 9 Algoritmusok s Bejárók 
e Bemeneti/kimeneti bejárók s Bejárások és predikátumok s Tagfüggvényeket használó 
algoritmusok e Algoritmusok (áttekintés) s Komplex számok "s Vektoraritmetika e A stan- 
dard könyvtár (áttekintés) s Tanácsok 


3.1. Bevezetés 


Nincs olyan jelentős program, mely csak a puszta programnyelven íródik. Először a nyelvet 
támogató könyvtárakat fejlesztik ki, ezek képezik a további munka alapját. 


A 2. fejezet folytatásaként ez a fejezet gyors körutazást tesz a fő könyvtári szolgáltatások- 
ban, hogy fogalmat adjon, mit lehet a C-- és standard könyvtárának segítségével megten- 
ni. Bemutat olyan hasznos könyvtári típusokat, mint a string, vector, list és map, valamint 


használatuk legáltalánosabb módjait. Ez lehetővé teszi, hogy a következő fejezetekben jobb 
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példákat és gyakorlatokat adjak az olvasónak. A 2. fejezethez hasonlóan bátorítani akarom 
az olvasót, ne zavarja, ne kedvetlenítse el, ha a részleteket nem érti tökéletesen. E fejezet 
célja, hogy megízleljük, mi következik, és megértsük a leghasznosabb könyvtári szolgálta- 
tások legegyszerűbb használatát. A standard könyvtárat részletesebben a §16.1.2 mutatja be. 


Az e könyvben leírt standard könyvtárbeli szolgáltatások minden teljes C----változat részét 
képezik. A C-4- standard könyvtárán kívül a legtöbb megvalósítás a felhasználó és a prog- 
ram közti párbeszédre grafikus felhasználói felületeket is kínál, melyeket gyakran GUI-k- 
nak vagy ablakozó rendszernek neveznek. Hasonlóképpen, a legtöbb programfejlesztő 
környezetet alapkönyvtárakkal (foundation library) is ellátták, amelyek a szabványos fej- 
lesztési és/vagy futtatási környezeteket támogatják. Ilyeneket nem fogunk leírni. A szándé- 
kunk a Csi önálló leírását adni, úgy, ahogy a szabványban szerepel, és megőrizni a példák 
,hordozhatóságát" (más rendszerekre való átültetésének lehetőségét), kivéve a külön meg- 
jelölteket. Természetesen biztatjuk az olvasót, fedezze fel a legtöbb rendszerben meglévő, 
kiterjedt lehetőségeket — ezt azonban a gyakorlatokra hagytuk. 


3.2. Helló, világ! 


A legkisebb C-t program: 


int mainO [ ) 


A program megadja a main nevű függvényt, melynek nincsenek paraméterei és nem tesz 
semmit. Minden C-4- programban kell, hogy legyen egy mainO nevű függvény. A program 
e függvény végrehajtásával indul. A main által visszaadott int érték, ha van ilyen, a prog- 
ram visszatérési értéke , a rendszerhez". Ha nincs visszatérési érték, a rendszer a sikeres be- 


fejezést jelző értéket kap vissza. Ha a mainO nem nulla értéket ad vissza, az hibát jelent. 


A programok jellemzően valamilyen kimenetet állítanak elő. Íme egy program, amely ki- 
írja: Helló, világ!. 


sinclude Ciostream: 


int mainŐ 


( 
sid::cout c£ "Helló, világ Nm"; 


7 
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Az $include Ciostream? utasítja a fordítót, hogy illessze be az iostream-ben található adat- 
folyam-bemeneti és -kimeneti szolgáltatások deklarációját a forráskódba. E deklarációk nél- 
kül az alábbi kifejezés 


std::cout Sz "Helló, világNn" 


értelmetlen volna. A cc ( tedd bele") kimeneti operátor második operandusát beírja az el- 
sőbe. Ebben az esetben a , Helló, világ Mn" karakterliterál a szabványos kimeneti adatfo- 
lyamba, az std::cout-ba íródik. A karakterliterál egy " " jelek közé zárt karaktersorozat. 
A benne szereplő A (backslash, fordított perjel az utána következő karakterrel valamilyen 
egyedi karaktert jelöl. Esetünkben az Wz az új sor jele, tehát a kiírt , Helló, világ! szöveget 
sortörés követi. 


3.3. A standard könyvtár névtere 


A standard könyvtár az szd névtérhez (42.4, 48.29) tartozik. Ezért írtunk std::cout-ot cout he- 
lyett. Ez egyértelműen a standard cout használatát írja elő, nem valamilyen más cout-ét. 


A standard könyvtár minden szolgáltatásának beépítéséről valamilyen, az Ciostream:-hez 
hasonló szabványos fejállomány által gondoskodhatunk: 


fincludecsstring2 
fincludedlist2- 


Ez rendelkezésre bocsátja a szabványos string-et és list-et. Használatukhoz az std:: előtagot 
alkalmazhatjuk: 


std::string s - "Négy láb jó, két láb rossz! ; 
std::listzstd::string2 slogans; 


Az egyszerűség kedvéért a példákban ritkán írjuk ki az szd:: előtagot, illetve a szükséges 
íinclude Sfejállomány:-okat. Az itt közölt programrészletek fordításához és futtatásához 
a megfelelő fejállományokat be kell építeni (include, amint a §3.7.5, §8.6 és a 16. fejezet- 
ben szereplő felsorolásokban szerepelnek). Ezenkívül vagy az sztd:: előtagot kell használni, 
vagy globálissá kell tenni minden nevet az szd névtérből (48.2.3): 
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tincludesstring: // a szabványos karakterlánc-szolgáltatások elérhetővé tétele 
using namespace std; // std nevek elérhetővé tétele az std:: előtag nélkül 
string s - "A tudatlanság erény! ; // rendben: a string jelentése std::string 


Általában szegényes ízlésre vall egy névtérből minden nevet a globális névtérbe helyezni. 
Mindazonáltal, a nyelvi és könyvtári tulajdonságokat illusztráló programrészletek rövidre 
fogása érdekében elhagytuk az ismétlődő $include-okat és std:: minősítéseket. E könyvben 
majdnem kizárólag a standard könyvtárat használjuk, ha tehát egy nevet használunk onnan, 
azt vagy a szabvány ajánlja, vagy egy magyarázat része (hogyan határozható meg az adott 
szabványos szolgáltatás). 


3.4. Kimenet 


Az iostream könyvtár minden beépített típusra meghatároz kimenetet, de felhasználói tí- 
pushoz is könnyen megadhatjuk. Alapértelmezésben a cout-ra kerülő kimeneti értékek 
karaktersorozatra alakítódnak át. A következő kód például az 7 karaktert a 0 karakterrel 
követve a szabványos kimeneti adatfolyamba helyezi. 


void JO 
( 


cout cZ 10; 


J 


Ugyanezt teszi az alábbi kód is: 


void gO 

( 
inti - 10; 
cout cz í; 


j 


A különböző típusú kimenetek természetesen párosíthatók: 


void h(int i) 

( 
cout c£ Vi értéke "; 
cout cz í; 


cout cz Mt 


J 
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Ha i értéke 70, a kimenet a következő lesz: 
i értéke 10 


A karakterkonstans egy karakter, egyszeres idézőjelek közé zárva. Vegyük észre, hogy 
a karakterkonstansok nem számértékként, hanem karakterként íródnak ki: 


void kO 
í 


cout cz a; 
cout cz b; 
cout cZ c; 


J 


A fenti kód kimenete például abc lesz.Az ember hamar belefárad a kimeneti adatfolyam ne- 
vének ismétlésébe, amikor több rokon tételt kell kiírni. Szerencsére maguk a kimeneti kife- 
jezések eredményei felhasználhatók további kimenetekhez: 


void hint í) 
( 
cout c£ !i értéke " cicc Mb 
J 
Ez egyenértékű h0-val. Az adatfolyamok részletes magyarázata a 21. fejezetben található. 


3.5. Karakterláncok 


A standard könyvtár gondoskodik a string (karakterlánc) típusról, hogy kiegészítse a koráb- 
ban használt karakterliterálokat. A szring típus egy sereg hasznos karakterlánc-műveletet 
biztosít, ilyen például az összefűzés : 


string s1 - "Helló"; 
string 52 - "világ"; 


void m1O 
( 


string s3-s1 4" "4 s24 "An; 


cout c£Z 53; 


J 
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Az s3 kezdeti értéke itt a következő karaktersorozat (új sorral követve): 


Helló, világ! 


A karakterláncok összeadása összetűzést jelent. A karakterláncokhoz karakterliterálokat és 
karaktereket adhatunk. Sok alkalmazásban az összetűzés legáltalánosabb formája valamit 
egy karakterlánc végéhez fűzni. Ezt a -- művelet közvetlenül támogatja: 


void m2(stringé s1, stringk s2) 
( 
s1-s14 Mint // sortörés 
524- Mt // sortörés 
j 
A lánc végéhez való hozzáadás két módja egyenértékű, de az utóbbit előnyben részesítjük, 
mert tömörebb és valószínűleg hatékonyabban valósítható meg.Természetesen a karakter- 
láncok összehasonlíthatók egymással és literálokkal is: 


string incantation; /[/varázsszó 


void respond(const stringk answer) 


( 


if (answer -- incantation) ( 
// varázslás megkezdése 


) 

else if (answer —— "yes") f 
ZAK 

) 

I éseg 


j 


A standard könyvtár síring osztályát a 20. fejezet írja le. Ez más hasznos tulajdonságai mel- 
lett lehetővé teszi a részláncok (substring) kezelését is. Például: 


string name - "Niels Stroustrup"; 


void m30 
( 
string s - name.substr(6, 109; // s 7 "Stroustrup" 
name.replace(0, 5, "Nicholas"; // a név új értéke "Nicholas Stroustrup" lesz 


j 


A substrÓ művelet egy olyan karakterláncot ad vissza, mely a paramétereivel megadott 
részlánc másolata. Az első paraméter egy, a karakterlánc egy adott helyére mutató sorszám, 
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a második a kívánt részlánc hossza. Mivel a sorszámozás (az index) O-tól indul, s a Strous- 
trup értéket kapja.A replaceO művelet a karakterlánc egy részét helyettesíti egy másik ka- 
rakterlánccal. Ebben az esetben a 0-val induló, 5 hosszúságú részlánc a Niels; ez helyette- 
sítődik a Nicholas-szal. A name végső értéke tehát Nicholas Stroustrup. Vegyük észre, hogy 
a helyettesítő karakterláncnak nem kell ugyanolyan méretűnek lennie, mint az a részlánc, 


amelyet helyettesít. 


3.5.1.C stílusú karakterláncok 


A C stílusú karakterlánc egy nulla karakterrel végződő karaktertömb (45.5.29. Meg fogjuk mu- 
tatni, hogy egy C stílusú karakterláncot könnyen bevihetünk egy siring-be. A C stílusú ka- 
rakterláncokat kezelő függvények meghívásához képesnek kell lennünk egy szring értéké- 
nek C stílusú karakterlánc formában való kinyerésére. A c strO függvény ezt teszi (§420.3.79. 
A namec-et a printfO kiíró C-függvénnyel (421.8) például az alábbi módon írathatjuk ki: 


void JO 
( 


brintf("name: 909 n" name.c str); 


J 


3.6. Bemenet 


A standard könyvtár bemenetre az istreams-et ajánlja. Az ostreams-hez hasonlóan az 
istreams is a beépített típusok karaktersorozatként történő ábrázolásával dolgozik és 
könnyen bővíthető, hogy felhasználói típusokkal is meg tudjon birkózni. A 5: (, olvasd be") 
műveleti jelet bemeneti operátorként használjuk; a cin a szabványos bemeneti adatfolyam. 
A 55 jobb oldalán álló típus határozza meg, milyen bemenet fogadható el és mi a beolvasó 
művelet célpontja. Az alábbi kód egy számot, például 123£-et olvas be a szabványos beme- 
netről az i egész változóba és egy lebegőpontos számot, mondjuk 1712.34e5-öt ír a kétszeres 
pontosságú, lebegőpontos d változóba: 


void JO 
( 
int í; 
cin 55 í; // egész szám beolvasása i-be 
double d; 
cin 55 d; // kétszeres pontosságú lebegőpontos szám beolvasása d-be 


J 
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A következő példa hüvelykről centiméterre és centiméterről hüvelykre alakít. Bemenetként 
egy számot kap, melynek végén egy karakter jelzi az egységet (centiméter vagy hüvelyk). 
A program válaszul kiadja a másik egységnek megfelelő értéket: 


int mainŐ 


( 
const float factor — 2.54; // 1 hüvelyk 2.54 cm-rel egyenlő 
float x, in, cm; 
char ch — 0; 


cout c£ Tírja be a hosszúságot: "; 


cin 55 Xx; // lebegőpontos szám beolvasása 
cin 55 ch; // mértékegység beolvasása 


switch (ch) f 


case üt: // inch (hüvelyk) 
in - x; 
cm - x" factor; 
break; 
case tet // cm 
in - x/factor; 
cm — x; 
break; 
default: 


in - cm — 0; 
break; 


J 


cout ££ in cz " in — " cz cm ca " cmnT 


A switch utasítás egy értéket hasonlít össze állandókkal. A break utasítások a switch utasí- 
tásból való kilépésre valók. A case konstansoknak egymástól különbözniük kell. Ha az el- 
lenőrzött érték egyikkel sem egyezik, a vezérlés a default-ot választja. A programozónak 
nem kell szükségszerűen erről az alapértelmezett lehetőségről gondoskodnia. 


Gyakran akarunk karaktersorozatot olvasni. Ennek kényelmes módja egy síring-be való 
helyezés: 


int mainO 


( 


string str; 
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cout c£ "írja be a nevétNm"; 
cin 55 SÍT; 
cout cz "Helló, " cz str cz INN; 


J 


Ha begépeljük a következőt 


Erik 


a válasz az alábbi lesz: 


Helló, Erik! 


Alapértelmezés szerint az olvasást egy ,üreshely" (whitespace) karakter (45.5.29, például 
egy szóköz fejezi be, tehát ha beírjuk a hírhedt király nevét 


Erik a Véreskezű 


a válasz marad 


Helló, Erik! 


A getlineO függvény segítségével egész sort is beolvashatunk: 
int mainŐ 
( 
string SÍT; 
cout c£ "írja be a nevétNm"; 
getlineccin, str); 


cout cz "Helló, " cz str cz INN; 


j 
E programmal az alábbi bemenet 
Erik a Véreskezű 


a kívánt kimenetet eredményezi: 


Helló, Erik a Véreskezű! 
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A szabványos karakterláncoknak megvan az a szép tulajdonságuk, hogy rugalmasan bőví- 
tik a tartalmukat azzal, amit beviszünk, tehát ha néhány megabájtnyi pontosvesszőt adunk 
meg, a program valóban több oldalnyi pontosvesszőt ad vissza — hacsak gépünk vagy az 
operációs rendszer valamilyen kritikus erőforrása előbb el nem fogy. 


3.7. Tárolók 


Sok számítás jár különböző objektumformákból álló gyűjtemények Ccollection) létrehozá- 
sával és kezelésével. Egy egyszerű példa karakterek karakterláncba helyezése, majd a ka- 
rakterlánc kiíratása. Az olyan osztályt, melynek fő célja objektumok tárolása, általánosan 
tárolónak (Ccontainer, konténer) nevezzük. Adott feladathoz megfelelő tárolókról gondos- 
kodni és ezeket támogatni bármilyen program építésénél nagy fontossággal bír. 


A standard könyvtár leghasznosabb tárolóinak bemutatására nézzünk meg egy egyszerű 
programot, amely neveket és telefonszámokat tárol. Ez az a fajta program, amelynek válto- 
Zatai az eltérő hátterű emberek számára is , egyszerűnek és maguktól értetődőnek" tűnnek. 


3.7.1. Vektor 


Sok C programozó számára alkalmas kiindulásnak látszana egy beépített (név- vagy szám-) 
párokból álló tömb: 


struct Entry f 
string name; 
int number; 


J; 


Entry phone book[1000/; 


void print entry(int i) // egyszerű használat 


( 


cout ££ phone bookl[ij. name cz ! ! cz phone bookl[ij.number cz Mm; 


J 


A beépített tömbök mérete azonban rögzített. Ha nagy méretet választunk, helyet pazaro- 
lunk; ha kisebbet, a tömb túl fog csordulni. Mindkét esetben alacsonyszintű tárkezelő kó- 
dot kell írnunk. A standard könyvtár a vector típust (416.3) bocsátja rendelkezésre, amely 
megoldja a fentieket: 
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vectorSEntry: phone book(1000); 


void print entry(int í) // egyszerű használat, mint a tömbnél 
j cout c£ bhone booklij. name cz ! ! cz phone bookl[ij. number cz Mi; 

J 

void add entries(int n) // méret növelése n-nel 

; bhone book.resizerbhone book.size0n); 

J 


A vector sizeO) tagfüggvénye megadja az elemek számát. Vegyük észre a ( zárójelek hasz- 
nálatát a phone book definíciójában. Egyetlen vectorsEntry: típusú objektumot hoztunk 
létre, melynek megadtuk a kezdeti méretét. Ez nagyon különbözik a beépített tömbök 
bevezetésétől: 


vectorsEntry2: book(1000);  // vektor 1000 elemmel 
vectorsEntry2 books[1000][;  // 1000 tres vektor 


Ha hibásan / /-t (szögletes zárójelet) használnánk ott, ahol egy vector deklarálásában 0-t 
értettünk, a fordító majdnem biztos, hogy hibaüzenetet ad, amikor a vector-t használni 
próbáljuk. 


A vector egy példánya objektum, melynek értéket adhatunk: 


void KvectorsEntry-g v) 
( 


vectorSEntry: v2 - phone book; 
v - 2 
18 

J 


A vector-ral való értékadás az elemek másolásával jár. Tehát /0-ben az előkészítés Ciniciali- 
zálás) és értékadás után vés v2is egy-egy külön másolatot tartalmaz a bhone book-ban lé- 
vő minden egyes Entry-ről. Ha egy vektor sok elemet tartalmaz, az ilyen ártatlannak látszó 
értékadások megengedhetetlenül , költségesek". Ahol a másolás nem kívánatos, referenciá- 
kat (hivatkozásoka0) vagy mutatókat kell használni. 


68 Bevezetés 


3.7.2. Tartományellenőrzés 


A standard könyvtárbeli vector alapértelmezés szerint nem gondoskodik tartományellenőr- 
zésről (416.3.3). Például: 


void JO 
( 


int i - bhone book[1001].number; . // az 1001 kívül esik a tartományon 
Ms 


j 
A kezdeti értékadás valószínűleg inkább valamilyen véletlenszerű értéket tesz í-be, mint 
hogy hibát okoz. Ez nem kívánatos, ezért a soron következő fejezetekben a vector egy egy- 
szerű tartományellenőrző átalakítását fogjuk használni, Vec néven. A Vec olyan, mint 
a vector, azzal a különbséggel, hogy out of range típusú kivételt vált ki, ha egy index kifut 
a tartományából. 


A Vec-hez hasonló típusok megvalósítási módjait és a kivételek hatékony használatát §11.12, 
§8.3 és a 14. fejezet tárgyalja. Az itteni definíció azonban elegendő a könyv példáihoz: 


templatexciass T- class Vec : public vectorzT: f 
bublic: 

VecO : vectorST:0 1 ? 

Vec(int s) : vectorST-(5) ( ) 


Ig operatorf Int i) ( return at(; ) // tartományellenőrzés 
const Ik operatorf [(Gint i) const ( return at(i; ) // tartományellenőrzés 


Az at(i) egy vector indexművelet, mely out of range típusú kivételt vált ki, ha paramétere 
kifut a vector tartományából (416.3.3). 


Visszatérve a nevek és telefonszámok tárolásának problémájához, most már használhatjuk 
a Vec-et, biztosítva, hogy a tartományon kívüli hozzáféréseket elkapjuk: 


VecsEntry: bhone book(1000); 


void print entry(int i) // egyszerű használat, mint a vektornál 


( 
cout ££ phone bookl[ij. name cz ! ! cz phone bookl[ij.number cz Mm; 


j 
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A tartományon kívüli hozzáférés kivételt fog kiváltani, melyet a felhasználó elkaphat: 


void JO 
f 
try ( 
for Gint i - O; i210000); i44) print entry(i); 


) 
catch (out of range) f 
cout 2 "tartományhibaMm "; 


) 
J 


A kivétel , dobása" majd elkapása akkor történik, amikor a phone booklij-re i--1000 érték- 
kel történik hozzáférési kísérlet. Ha a felhasználó nem kapja el ezt a fajta kivételt, a prog- 
ram meghatározott módon befejeződik; nem folytatja futását és nem vált ki meghatáro- 
zatlan hibát. A kivételek okozta meglepetések csökkentésének egyik módja, ha a mainŐ 
törzsében egy try blokkot hozunk létre: 


int mainŐ 


nyi 
// saját kód 
J 
catch (out of range) f 
cerr 22 "tartományhiba "; 


J 
catch (...) ( 
cerr ££ "ismeretlen kivételNm"; 


J 


Ez gondoskodik az alapértelmezett kivételkezelőkről, tehát ha elmulasztunk elkapni egy ki- 
vételt, a cerr szabványos hibakimeneti adatfolyamon hibajelzés jelenik meg (§21.2.1. 


3.7.3. Lista 


A telefonkönyv-bejegyzések beszúrása és törlése általánosabb lehet, ezért egy egyszerű te- 
lefonkönyv ábrázolására egy lista jobban megfelelne, mint egy vektor: 


listzEntry: phone book; 


Amikor listát használunk, az elemekhez nem sorszám alapján szeretnénk hozzáférni, ahogy 
a vektorok esetében általában tesszük. Ehelyett átkutathatjuk a listát, adott értékű elemet 


keresve. 
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Ehhez kihasználjuk azt a tényt, hogy a list egy sorozat (43.98): 


void print entry(const stringft 5) 


( 


typedef listzEntry2::const iterator LI; 


for (II i - phone book.beginO); i !/- phone book.endO; 47-i) f 
Entrykg e — ?i; // rövidítés referenciával 
if (s -—- e.name) ( 
cout ££ e.name ca ! ! cz enumber cz MM; 
return; 


J 


j 

Az s keresése a lista elejénél kezdődik, és addig folytatódik, míg az s-t megtaláljuk vagy el- 
érünk a lista végéhez. Minden standard könyvtárbeli tároló tartalmazza a beginŐ és endŐ 
függvényeket, melyek egy bejárót (iterátort) adnak vissza az első, illetve az utolsó utáni 
elemre (416.3.2). Ha adott egy i bejáró, a következő elem ---i lesz. Az i változó a ti elemre 
hivatkozik. A felhasználónak nem kell tudnia, pontosan milyen típusú egy szabványos tá- 
roló bejárója. A típus a tároló leírásának része és név szerint lehet hivatkozni rá. Ha nincs 
szükségünk egy tárolóelem módosítására, a const iterator az a típus, ami nekünk kell. Kü- 
lönben a sima iterator típust (§16.3.1) használjuk. 


Elemek hozzáadása egy /ist-hez igen könnyű: 


void add entry(const Entryé e, listcEntry2::iterator í) 


( 
phone bookpush front(e9; // hozzáadás a lista elejéhez 
phone book.push back(e); // hozzáadás a lista végéhez 
phone book.insert(i, e); // hozzáadás az 1 által mutatott elem elé 


j 


3.7.4. Asszociatív tömbök 


Egy név- vagy számpárokból álló listához kereső kódot írni valójában igen fáradságos mun- 
ka. Ezenkívül a sorban történő keresés — a legrövidebb listák kivételével — nagyon rossz ha- 
tékonyságú. Más adatszerkezetek közvetlenül támogatják a beszúrást, a törlést és az érték 
szerinti keresést. A standard könyvtár nevezetesen a map típust biztosítja erre a feladatra 
(417.4.1). A map egy értékpár-tároló. Például: 


mapsstring,int- pbhone book; 
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Más környezetekben a map mint asszociatív tömb vagy szótár szerepel. Ha első típusával 
(a kulccsal, key) indexeljük, a map a második típus (az érték, vagyis a hozzárendelt típus, 


mapped type) megfelelő értékét adja vissza: 


void print entry(const stringé 5) 


if (inti - phone bookl[s) cout ccszz! Pc icz MM; 


J 


Ha nem talál illeszkedést az s kulcsra, a bhone book egy alapértéket ad vissza. A map alap- 
értéke int típusra O. Itt feltételezzük, hogy a 0 nem érvényes telefonszám. 


3.7.5. Szabványos tárolók 


Az asszociatív tömb, a lista és a vektor mind használható telefonkönyv ábrázolására. Mind- 
egyiknek megvannak az erős és gyenge oldalai. A vektorokat indexelni , olcsó" és könnyű. 
Másrészt két eleme közé egyet beszúrni költségesebb lehet. A lista tulajdonságai ezzel pon- 
tosan ellentétesek. A map emlékeztet egy (kulcs-érték) párokból álló listára, azzal a kivé- 


tellel, hogy értékei a kulcs szerinti kereséshez a legmegfelelőbbek. 


A standard könyvtár rendelkezik a legáltalánosabb és leghasználhatóbb tárolótípusokkal, 
ami lehetővé teszi, hogy a programozók olyan tárolót válasszanak, mely az adott alkalma- 
zás igényeit a legjobban kiszolgálja: 











Szabványos tárolók összefoglalása 
VectorST- Változó hosszúságú vektor (416.3) 
listzT- Kétirányú láncolt lista (417.2.2 
OueuesT- Sor (417.3.2) 
StackcT: Verem (§17.3.1) 
DeguesT:- Kétvégű sor (417.2.3) 
Priority gueuezT- Érték szerint rendezett sor (§17.3.3) 
sel£T: Halmaz (§17.4.3) 
MultisetzT- Halmaz, melyben egy érték többször 
is előfordulhat (417.4.4) 
Mapckulcs, érték: Asszociatív tömb (§17.4.1) 
Multimapckulcs, érték: Asszociatív tömb, melyben egy kulcs többször 
előfordulhat (§17.4.2) 
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A szabványos tárolókat §16.2, §16.3 és a 17. fejezet mutatja be. A tárolók az sid névtérhez 
tartoznak, leírásuk a cvector:, clist2, Cmap? stb. fejállományokban szerepel. A szabványos 
tárolók és alapműveleteik jelölés szempontjából hasonlóak, továbbá a műveletek jelentése 
a különböző tárolókra nézve egyforma. Az alapműveletek általában mindenfajta tárolóra al- 
kalmazhatók. A push backO például — meglehetősen hatékony módon - egyaránt használ- 
ható elemeknek egy vektor vagy lista végéhez fűzésére, és minden tárolónak van size tag- 
függvénye, mely visszaadja az elemek a számát.Ez a jelölésbeli és jelentésbeli egységesség 
lehetővé teszi, hogy a programozók új tárolótípusokat készítsenek, melyek a szabványos tí- 
pusokhoz nagyon hasonló módon használhatók. A Vec tartományellenőrzéssel ellátott vek- 
tor (§3.7.6) ennek egy példája. A 17. fejezet bemutatja, hogyan lehet egy hash map-et 
a szerkezethez hozzátenni. A tárolófelületek egységes volta emellett lehetővé teszi azt is, 
hogy az egyes tárolótípusoktól függetlenül adjunk meg algoritmusokat. 


3.8. Algoritmusok 


Az adatszerkezetek, mint a /ist vagy a vector, önmagukban nem túl hasznosak. Használa- 
tukhoz olyan alapvető hozzáférési műveletekre van szükség, mint az elemek hozzáadása és 
eltávolítása. Emellett ritkán használunk egy tárolót pusztán tárolásra. Rendezzük, kiíratjuk, 
részhalmazokat vonunk ki belőlük, elemeket távolítunk el, objektumokat keresünk bennük 
és így tovább. Emiatt a standard könyvtár az általános tárolótípusokon kívül biztosítja a tá- 
rolók legáltalánosabb eljárásait is. A következő kódrészlet például egy veczor-t rendez és 
minden egyedi vector elem másolatát egy /ist-be teszi: 


void fwvectorsEntry-é ve, listcEntry-é le) 


( 
sort(ve.beginO, ve.endO ); 


unigue copy(ve.beginO, ve.endO, le.beginO; 
) 


J 

A szabványos algoritmusok leírását a 18. fejezetben találjuk. Az algoritmusok elemek soro- 
zatával működnek (42.7.2). Az ilyen sorozatok bejáró-párokkal ábrázolhatók, melyek az el- 
ső, illetve az utolsó utáni elemet adják meg. A példában a sortÓ rendezi a sorozatot, 
ve.beginŐ-től ve.endŐ-ig, ami éppen a vector összes elemét jelenti. Íráshoz csak az első 
írandó elemet szükséges megadni. Ha több mint egy elemet írunk, a kezdő elemet követő 
elemek felülíródnak. Ha az új elemeket egy tároló végéhez kívánnánk adni, az alábbit ír- 
hatnánk: 
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void KvectorsEntryzé ve, listcEntryzk le) 


í 
sort(ve.beginO, ve.endO 9; 
unigue copy(ve.beginO, ve.endO, back. inserter(le)); // hozzáfűzés le-hez 


J 


A back inserterŐ elemeket ad egy tároló végéhez, bővítve a tárolót, hogy helyet csináljon 
részükre (419.2.4) . A szabványos tárolók és a back inserterŐ-ek kiküszöbölik a hibalehető- 
séget jelentő, C stílusú reallocO-ot használó tárkezelést (416.3.5). Ha a hozzáfűzéskor elfe- 
lejtjük a back inserterO-t használni, az hibákhoz vezethet: 


void KvectorsEntryzé ve, listcEntryzk le) 


( 
copy(ve.beginO,ve.endO, le); // hiba: le nem bejáró 
copy(ve.beginO, ve.endO,le.endO ); // rossz: túlír a végén 
copy(ve.beginO, ve.endO, le.begin); // elemek felülírása 

J 


3.8.1. Bejárók használata 


Amikor először találkozunk egy tárolóval, megkaphatjuk néhány hasznos elemére hivatko- 
zó bejáróját Citerátorán; a legjobb példa a beginŐ és az endOŐ. Ezenkívül sok algoritmus ad 
vissza bejárókat. A find szabványos algoritmus például egy sorozatban keres egy értéket és 
azt a bejárót adja vissza, amely a megtalált elemre mutat. Ha a find-ot használjuk, megszám- 
lálhatjuk valamely karakter előfordulásait egy karakterláncban: 


int count(const stringé s, char c) // c előfordulásainak megszámlálása s-ben 


í 
intn —- 0; 
string::const iterator i - find(s.beginO,s.endO, c); 
while (i !- s.endO) f 
4; 
i - find(i31,5.endO, c); 
) 


return n; 


J 


A find algoritmus valamely érték egy sorozatban való első előfordulására vagy a sorozat 
utolsó utáni elemére mutató bejárót ad vissza. Lássuk, mi történik a count egyszerű meghí- 
vásakor: 
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void JO 
( 


string m - "Mary had a little lamD"; 
int a count - count(m, a); 


J 


A findO első hívása megtalálja "a-t a Mary-ben. A bejáró tehát e karakterre mutat és nem az 
s.endO-re, így beléptünk a ciklusba. A ciklusban i--71-gyel kezdjük a keresést; vagyis eggyel 
a megtalált "d után. Ezután folytatjuk a ciklust és megtaláljuk a másik három "a-t. A findO 
ekkor elér a sorozat végéhez és az s.endO-et adja vissza, így nem teljesül az i/-s.endő felté- 
tel és kilépünk a ciklusból. Ezt a countO hívást grafikusan így ábrázolhatnánk: 


; Po hd 


im[alr [9 nja[a] elél 





a l e l]lalmi]b 

































































A nyilak az i kezdeti, közbenső és végső értékeit mutatják. 


Természetesen a find algoritmus minden szabványos tárolón egyformán fog működni. Kö- 
vetkezésképpen ugyanilyen módon általánosíthatnánk a countO függvényt: 


templatexclass CG, class T: int count(const Cg v, T val 


( 
tybename C::const iterator i - find(v.beginŐ, v.endO, vaD; // typename, lásd §C.13.5 
intn - 0; 
while (i !- v.endO) ( 
tetett 
ti; // az előbb megtalált elem átugrása 
i — find(i,v.endO, vaD; 
J 
return n; 


j 


Ez működik, így mondhatjuk: 


void f(listccomplex-k lc, vectorsstring:£ vc, string 5) 
t 

int il - count(lc,complex(1,3); 

int i2 - count(vc, "Diogenész"; 

int i3 — count(s, X; 


J 
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A count sablont azonban nem kell definiálnunk. Az elemek előfordulásainak megszámlálá- 
sa annyira általános és hasznos, hogy a standard könyvtár tartalmazza ezt a műveletet. Hogy 
teljesen általános legyen a megoldás, a standard könyvtári count paraméterként tároló he- 
lyett egy sorozatot kap: 


void f(distzcomplex-k lc, vectorsstring:£ vs, string 5) 


ff 
t 


int i1 - count(lc.beginO, lc.endO, complexC1,3) 9; 
int i2 - count(vs.beginO, vs.endO, "Diogenész"; 
int i3 - count(s.beginO, s.endO, Xx); 

) 


A sorozat használata megengedi, hogy a számlálást beépített tömbre használjuk és azt is, 
hogy egy tároló valamely részét számláljuk: 


void g(char cs[ J, int sz) 


f 

int il - count(£cs(0/,£ csiszi, 27; // z-k a tömbben 

int i2 - count(£csl(0/,8 csisz/21,z9;  / 2-k a tömb első felében 
; 


3.8.2. Bejárótípusok 


Valójában mik is azok a bejárók (iterátorok)? Minden bejáró valamilyen típusú objektum. 
Azonban sok különböző típusuk létezik, mert a bejárónak azt az információt kell tárolnia, 
melyre az adott tárolótípusnál feladata ellátásához szüksége van. Ezek a bejárótípusok 
olyan különbözők lehetnek, mint a tárolók és azok az egyedi igények, melyeket kiszolgál- 
nak. Egy vector bejárója például minden bizonnyal egy közönséges mutató, mivel az na- 
gyon ésszerű hivatkozási mód a vector elemeire: 


bejáró: Élt 


vektor: Plilelt Hl]leliln 
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Egy vector-bejáró megvalósítható úgy is, mint a vector-ra hivatkozó mutató, meg egy sor- 
szám: 





bejáró: (kezdet -- p, pozició —— 3) 
vektor: Plilelt HI]leliln 
































Az ilyen bejárók használata tartományellenőrzésre is lehetőséget ad (419.3). 


A listák bejáróinak valamivel bonyolultabbnak kell lenniük, mint egy egyszerű mutató a lis- 
tában tárolt elemre, mivel egy ilyen elem általában nem tudja, hol van a lista következő tag- 
ja. A lista-bejáró tehát inkább a lista valamely csomópontjára hivatkozó mutató: 


bejáró: b 


; 


lista: csomópont -m-] cs. — ze] cs. J—mt] cs. [5 ... 
































elemek: P i e t 


Ami közös minden bejárónál, az a jelentésük és a műveleteik elnevezése. A --4 alkalmazá- 
sa bármely bejáróra például olyan bejárót ad, mely a következő elemre hivatkozik. Hason- 
lóképpen " azt az elemet adja meg, melyre a bejáró hivatkozik. Valójában bejáró lehet bár- 
mely objektum, amely néhány, az előzőekhez hasonló egyszerű szabálynak eleget tesz 
(§19.2.10. Továbbá, a felhasználó ritkán kell, hogy ismerje egy adott bejárótípusát. Saját 
bejáró-típusait minden tároló ismeri és azokat az egyezményes iterator és const iteratorne- 
veken rendelkezésre bocsátja. Például a listcEntry2::iterator a listcEntry: általános bejáró- 
típusa. Ritkán kell aggódnunk az adott típus meghatározása miatt. 
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3.8.3. Bemeneti és kimeneti bejárók 


A bejárók fogalma általános és hasznos a tárolók elemeiből álló sorozatok kezelésénél. A tá- 
rolók azonban nem az egyetlen helyet jelentik, ahol elemek sorozatát találjuk. A bemeneti 
adatfolyamok is értékek sorozatából állnak, és értékek sorozatát írjuk a kimeneti adatfo- 
lyamba is. Következésképpen a bejárók hasznosan alkalmazhatók a bemenetnél és kime- 
netnél is. 


Egy ostream, iterator létrehozásához meg kell határoznunk, melyik adatfolyamot használ- 


juk és milyen típusú objektumokat írunk bele. Megadhatunk például egy bejárót, mely 
a cout szabványos kimeneti adatfolyamra hivatkozik: 


ostream iteratorsstring2 00(CcOUU; 


Az értékadás "oo-nak azt jelenti, hogy az értékadó adatot a cout-ra írjuk ki. Például: 


int mainŐ 
00 - "Helló, "; — // jelentése cout cz "Helló, " 
4400; 
00 — WwilágNn";  // jelentése cout cz "WwilágNm" 
j 


Ez egy újabb mód szabványos üzenetek kiírására a szabványos kimenetre. A 4-oo célja: 
utánozni egy tömbbe mutatón keresztül történő írást. A szerző elsőnek nem ezt a módot vá- 
lasztaná erre az egyszerű feladatra, de ez az eszköz alkalmas arra, hogy a kimenetet úgy ke- 
zeljük, mint egy csak írható tárolót, ami hamarosan magától értetődő lesz — ha eddig még 


nem lenne az. 


Hasonlóképpen az istream. iterator olyasvalami, ami lehetővé teszi, hogy a bemeneti adat- 
folyamot úgy kezeljük, mint egy csak olvasható tárolót. Itt is meg kell adnunk a használni 
kívánt adatfolyamot és a várt értékek típusát: 


istream, iteratorsstring? ii(cin); 


Mivel a bejárók mindig párokban ábrázolnak egy sorozatot, a bemenet végének jelzéséhez 
egy istream, iterator-ról kell gondoskodni. Az alapértelmezett istream iterator a következő: 


istream iteratorsstring2 eos; 
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Most újra beolvashatnánk a , Hellő, világot/"-ot a bemenetről és kiírathatnánk az alábbi 
módon: 


int mainŐ 


string s1 — "ii; 
4; 
string s2 — "ii; 


cout cs] cc! ccs2ce nt 


Valójában az istream iterator-okat és ostream  iterator-okat nem közvetlen használatra ta- 
lálták ki. Jellemzően algoritmusok paramétereiként szolgálnak. Írjunk például egy egysze- 
rű programot, mely egy fájlból olvas, az olvasott adatokat rendezi, a kétszer szereplő ele- 
meket eltávolítja, majd az eredményt egy másik fájlba írja: 


int mainŐ 


( 
string from, to; 
cin 25 from 525 to; // a forrás- és célfájl nevének beolvasása 
ifstream is(from.c. StrO); // bemeneti adatfolyam (c strO, lásd §3.5.1 és §20.3.7) 
istream, iteratorsstring? ii(is); // bemeneti bejáró az adatfolyam számára 
istream, iteratorsstring? eos; // bemenet-ellenőrzés 
vectorsstring: b(ii,e0o5); // b egy vektor, melynek a bemenetről adunk kezdőértéket 


sort(b.beginO,b.endO; // az átmeneti tár (b) rendezése 


ofstream os(to.c StrO); // kimeneti adatfolyam 
ostream, iteratorsstring: o00(os,Nn;  — // kimeneti bejáró az adatfolyam számára 


unigue copy(b.beginO, b.endO, 009; // b tartalmának a kimenetre másolása, 
// a kettőzött értékek elvetése 


return !is.eofO 11 Jos; // hibaállapot visszaadása (§3.2, §21.3.3) 


Az ifstream egy istream, mely egy fájlhoz kapcsolható, az o/jstream pedig egy ostream, 
mely szintén egy fájlhoz kapcsolható. Az ostream iterator második paramétere a kimeneti 
értékeket elválasztó jel. 
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3.8.4. Bejárások és predikátumok 


A bejárók lehetővé teszik, hogy ciklusokat írjunk egy sorozat bejárására. A ciklusok meg- 
írása azonban fáradságos lehet, ezért a standard könyvtár módot ad arra, hogy egy adott 
függvényt a sorozat minden egyes elemére meghívjunk. Tegyük fel, hogy írunk egy progra- 
mot, mely a bemenetről szavakat olvas és feljegyzi előfordulásuk gyakoriságát. A karakter- 
láncok és a hozzájuk tartozó gyakoriságok kézenfekvő ábrázolása egy map-pel történhet: 


mapsstring, int: histogram; 


Az egyes karakterláncok gyakoriságának feljegyzésére természetes művelet a következő: 


void record(const stringéz 5) 


( 


histogramis]4-t; — // "s" gyakoriságának rögzítése 


J 


Ha beolvastuk a bemenetet, szeretnénk az összegyűjtött adatokat a kimenetre küldeni. 
A map (string, in9) párokból álló sorozat. Következésképpen szeretnénk meghívni az aláb- 
bi függvényt 


void print(const paircconst string, int:£ r) 


( 


cout cz r.first Sz ! ! 2£ r.second 2 MM; 


J 


a map minden elemére (a párok (bair) első elemét /irst-nek, második elemét second-nak 
nevezzük). A pair első eleme const string, nem sima string, mert minden map kulcs 
konstans. 


A főprogram tehát a következő: 


int mainŐ 


istream iteratorsstring? i i(cin); 
istream iteratorsstring2 eos; 


for. each(ti, eos, record); 
for. each(histogram.beginO, histogram.endO print); 
j 
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Vegyük észre, hogy nem kell rendeznünk a map-et ahhoz, hogy a kimenet rendezett le- 
gyen. A map rendezve tárolja az elemeket és a ciklus is (növekvő) sorrendben járja végig 
a mapecet. 


Sok programozási feladat szól arról, hogy meg kell keresni valamit egy tárolóban, ahelyett, 
hogy minden elemen végrehajtanánk egy feladatot. A find algoritmus (418.5.2) kényelmes 
módot ad egy adott érték megkeresésére. Ennek az ötletnek egy általánosabb változata 
olyan elemet keres, mely egy bizonyos követelménynek felel meg. Például meg akarjuk ke- 
resni egy map első 42-nél nagyobb értékét: 


bool gt 42(const paircconst string, int:£ r) 


( 


return r.second:42; 


j 


void (mapsstring, int:k m) 


( 
typedef mapsstring, int:::const iterator MI; 
MI i - find if(m.beginO m.endO gt 429; 
VSE 


J 


Máskor megszámlálhatnánk azon szavakat, melyek gyakorisága nagyobb, mint 42: 


void e(const mapscstring,int:k m) 
; int c42 - count if(m.beginO  m.endO, et 429; 
A a) 

j 
Az olyan függvényeket, mint a gt 420, melyet az algoritmus vezérlésére használunk, pre- 
dikátumnak C( állítmány", vezérlőfüggvény, predicate) nevezzük. Ezek minden elemre 
meghívódnak és logikai értéket adnak vissza, melyet az algoritmus szándékolt tevékenysé- 
gének elvégzéséhez felhasznál. A find ifÖ például addig keres, amíg a predikátuma true-t 
nem ad vissza, jelezvén, hogy a kért elemet megtalálta. Hasonló módon a count ifO annyit 
számlál, ahányszor a predikátuma true. 


A standard könyvtár néhány hasznos predikátumot is biztosít, valamint olyan sablonokat, 
melyek továbbiak alkotására használhatók (418.4.2). 
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3.8.5. Tagfüggvényeket használó algoritmusok 


Sok algoritmus alkalmaz függvényt egy sorozat elemeire. Például §3.8.4-ben a 


for. each(ti, eos, record); 
meghívja a recordO-ot minden egyes, a bemenetről beolvasott karakterláncra. 


Gyakran mutatók tárolóival van dolgunk, és sokkal inkább a hivatkozott objektum egy tag- 
függvényét szeretnénk meghívni, nem pedig egy globális függvényt, a mutatót paraméter- 
ként átadva. Tegyük fel, hogy a Shape::drawO tagfüggvényt akarjuk meghívni egy 
listcShape:" elemeire. A példa kezelésére egyszerűen egy nem tag függvényt írunk, mely 
meghívja a tagfüggvényt: 


void drau(Shape? p) 


b--CdrawO; 
J 


void f((listcShape"-k sh) 


for. each(sh.beginO,sh.endO, draw); 
) 


A módszert így általánosíthatjuk: 
void g(listcShapet-£k sh) 


for. each(sh.beginO,sh.endO,mem fun(dShape::draw)); 
j 


A standard könyvtári mem funO sablon (§18.4.4.2) paraméterként egy tagfüggvény muta- 
tóját kapja (§15.5) és valami olyasmit hoz létre, amit a tag osztályára hivatkozó mutatón ke- 
resztül hívhatunk meg. A mem fun(ksShape::draw) eredménye egy Shape" paramétert kap 
és visszaadja, amit a Shape::drawO visszaad. 


A mem funO azért fontos, mert megengedi, hogy a szabványos algoritmusokat többalakú 
(polimorf) objektumok tárolóira használjuk. 
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3.8.6. A standard könyvtár algoritmusai 


Mi az algoritmus? Általános meghatározása szerint ,szabályok véges halmaza, mely adott 
problémahalmaz megoldásához műveletek sorozatát határozza meg és öt fontos jellemzője 
van: végesség, meghatározottság, bemenet, kimenet, hatékonyság" IKnuth,1968, §1.1]. 
A C44 standard könyvtárának viszonylatában az algoritmus elemek sorozatán műveleteket 
végző sablonok (template-ek) halmaza. 


A standard könyvtár több tucat algoritmust tartalmaz. Az algoritmusok az szid névtérhez tar- 
toznak, leírásuk az calgorithm:? fejállományban szerepel. Íme néhány, melyeket különösen 
hasznosnak találtam: 





Válogatott szabványos algoritmusok 











Jfor.eachO Hívd meg a függvényt minden elemre (§418.5.1) 

jfindO Keresd meg a paraméterek első előfordulását 
(§18.5.2) 

find ifO Keresd meg a predikátumra az első illeszkedést 
(§18.5.2) 

countO Számláld meg az elem előfordulásait (418.5.3) 

count ifO Számláld meg az illeszkedéseket a predikátumra 
(§18.5.3) 

replaceO Helyettesítsd be az elemet új értékkel (418.6.4) 


replace ifO 


copyO 

unigue copyO 
sortO 

egual rangeO 


mergeO 


Helyettesítsd be a predikátumra illeszkedő elemet 
új értékkel (418.6.4) 

Másold az elemeket (§418.6.1) 

Másold a csak egyszer szereplő elemeket (418.6.1) 
Rendezd az elemeket (418.7.1) 

Keresd meg az összes egyező értékű elemet 
(418.7.2) 

Fésüld össze a rendezett sorozatokat (§18.7.3) 








3.9. Matematika 


A C-hez hasonlóan a Csi nyelvet sem elsősorban számokkal végzett műveletekre tervez- 
ték. Mindemellett rengeteg numerikus munkát végeztek C-t--ban és ez tükröződik a stan- 
dard könyvtárban is. 
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3.9.1. Komplex számok 


A standard könyvtár a komplex számok egy típuscsaládját tartalmazza, a §2.5.2-ben leírt 
complex osztály alakjában. Az egyszeres pontosságú lebegőpontos (/loat), a kétszeres pon- 
tosságú (double) stb. skalárokat tartalmazó komplex számok támogatására a standard 
könyvtárbeli complex egy sablon: 


templatecciass scalar: class complex ( 
pbublic: 
complex(scalar re, scalar im); 


274 
); 


A szokásos aritmetikai műveletek és a leggyakrabban használt matematikai függvények 
komplex számokkal is működnek: 


// szabványos exponenciális függvény a ccomplex- sablonból: 
templatexclass Cs complexZC: pou(const complexzCck, in); 


void (complexszfloat: jl, complexzdouble: db) 


( 
complexzlong double: id — fl--sgrt(db); 
db 3— fT3; 
JJ - pow(1fl, 2; 
ése 

J 


Részletesebben lásd §22.5. 


3.9.2. Vektoraritmetika 


A §3.7.1-ben leírt vector-t általános értéktárolásra tervezték; kellően rugalmas és illeszkedik 
a tárolók, bejárók és algoritmusok szerkezetébe, ugyanakkor nem támogatja a matematikai 
vektorműveleteket. Ilyen műveleteket könnyen be lehetett volna építeni a vector-ba, de az 
általánosság és rugalmasság eleve kizár olyan optimalizálásokat, melyeket komolyabb, szá- 
mokkal végzett munkánál gyakran lényegesnek tekintünk. Emiatt a standard könyvtárban 
megtaláljuk a valarray nevű vektort is, mely kevésbé általános és a számműveletekhez job- 
ban megfelel: 


templatexclass T- class valarray ( 
VAS 
Tk operatorf size 1; 
AES 

J; 
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A size telőjel nélküli egész típus, melyet a nyelv tömbök indexelésére használ. A szokásos arit- 
metikai műveleteket és a leggyakoribb matematikai függvényeket megírták a valarray-kre is: 


// szabványos abszolútérték-függvény a Cvalarray: sablonból: 
templatexclass T- valarrayST: abs(const valarrayczT-£ J; 


void fvalarrayzdouble:k al, valarrayzdoublezk a2) 


( 


valarrayzdouble: a - a1"3.14ta2a1; 
a2 1- a1"3.14; 

a — abs(a); 

double d - a2/7]; 

CAO 


Részletesebben lásd: §22.4 


3.9.3. Alapszintű numerikus támogatás 


A standard könyvtár a lebegőpontos típusokhoz természetesen tartalmazza a leggyakoribb 
matematikai függvényeket (/ogO, powO és cos) lásd §2.2.3). Ezenkívül azonban tartalmaz 
olyan osztályokat is, melyek beépített típusok tulajdonságait — például egy /loat kitevőjének 
lehetséges legnagyobb értékét -írják le (ásd 422.29. 


3.10. A standard könyvtár szolgáltatásai 


A standard könyvtár szolgáltatásait az alábbi módon osztályozhatjuk: 


1. 


4. 


Alapvető futási idejű támogatás (pl. tárlefoglalás és futási idejű típusinformáció), 
lásd §16.1.3. 


. A szabványos C könyvtár (nagyon csekély módosításokkal, a típusrendszer 


megsértésének elkerülésére), lásd §16.1.2. 


. Karakterláncok és bemeneti/kimeneti adatfolyamok (nemzetközi karakterkész- 


let és nyelvi támogatással), lásd 20. és 21. fejezet. 
Tárolók (vector, list és map) és tárolókat használó algoritmusok (általános bejá- 
rások, rendezések és összefésülések) rendszere, lásd 16., 17., 18. és 19.fejezet. 
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5. Számokkal végzett műveletek támogatása (komplex számok és vektorok aritme- 


tikai műveletekkel), BLAS-szerű és általánosított szeletek, valamint az optimali- 
zálást megkönnyítő szerkezetek, lásd 22. fejezet. 


Annak fő feltétele, hogy egy osztály bekerülhet-e a könyvtárba, az volt, hogy valamilyen 
módon használta-e már majdnem minden Ct-4 programozó (kezdők és szakértők egy- 
aránt), hogy általános alakban megadható-e, hogy nem jelent-e jelentős többletterhelést 
ugyanennek a szolgáltatásnak valamely egyszerűbb változatához viszonyítva, és hogy 
könnyen megtanulható-e a használata. A Cs- standard könyvtára tehát az alapvető adat- 
szerkezeteket és az azokon alkalmazható alapvető algoritmusokat tartalmazza. 


Minden algoritmus átalakítás nélkül működik minden tárolóra. Ez az egyezményesen STL- 
nek (Standard Template Library, szabványos sablonkönyvtár) IStepanov, 1994] nevezett váz 
bővíthető, abban az értelemben, hogy a felhasználók a könyvtár részeként megadottakon 
kívül könnyen készíthetnek saját tárolókat és algoritmusokat, és ezeket azonnal működtet- 


hetik is a szabványos tárolókkal és algoritmusokkal együtt. 


3.11. Tanácsok 


[1] Ne találjunk fel a melegvizet — használjunk könyvtárakat. 

[2] Ne higgyünk a csodákban. Értsük meg, mit tesznek könyvtáraink, hogyan 
teszik, és milyen áron teszik. 

[3] Amikor választhatunk, részesítsük előnyben a standard könyvtárat más könyvtá- 
rakkal szemben. 

[4] Ne gondoljuk, hogy a standard könyvtár mindenre ideális. 

[5] Ne felejtsük el beépíteni ($include) a felhasznált szolgáltatások fejállományait. 
§3.3. 

[6] Ne felejtsük el, hogy a standard könyvtár szolgáltatásai az szd névtérhez tartoz- 
nak. §3.3. 

[7] Használjunk string-et char" helyett. §3.5, §3.6. 

[8] Ha kétségeink vannak, használjunk tartományellenőrző vektort (mint a VWeo). 
43.7.2. 

[9] Részesítsük előnyben a vectorsT--t, a listcT--t és a mapckey, value: -t a T/ /-vel 
szemben. §3.7.1, §3.7.3, §3.7.4. 
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[10] Amikor elemeket teszünk egy tárolóba, használjunk push backO-et vagy 
back inserterŐ-t. §3.7.3, §3.8. 

[11] Használjunk vektoron push backO-et a reallocO tömbre való alkalmazása 
helyett. §3.8. 

[12] Az általános kivételeket a mainO-ben kapjuk el. §3.7.2. 


Első rész 
Alapok 


Ez a rész a C44 beépített típusait és azokat az alapvető lehetőségeket írja le, amelyekkel 
programokat hozhatunk létre. A C$--nak a C nyelvre visszautaló része a hagyományos 
programozási stílusok támogatásával együtt kerül bemutatásra, valamint ez a rész tárgyalja 
azokat az alapvető eszközöket is, amelyekkel C--: programot hozhatunk létre logikai és fi- 
zikai elemekből. 


Fejezetek 


Típusok és deklarációk 
Mutatók, tömbök és struktúrák 
Kifejezések és utasítások 
Függvények 

Névterek és kivételek 
Forrásfájlok és programok 


SZAKOS ES VESZ 





Típusok és deklarációk 


, Ne fogadj el semmit, ami 
nem tökéletes!" 
(ismeretlen szerző) 


, A tökéletesség csak az össze- 
omlás pontján érhető el." 
(C.N. Parkinson) 


Típusok s Alaptípusok s Logikai típusok s Karakterek "s Karakterliterálok s Egészek e 
Egész literálok s Lebegőpontos típusok s Lebegőpontos literálok s Méretek e void s Felso- 
roló típusok e Deklarációk 9 Nevek s Hatókörök e Kezdeti értékadás e Objektumok e 
typedef-ek s Tanácsok e Gyakorlatok 
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4.1. Típusok 


Vegyük az 
x - yr (29; 


kifejezést. Hogy ez értelmes legyen valamely C-4-- programban, az x, y és fneveket megfe- 
lelően definiálni kell, azaz a programozónak meg kell adnia, hogy ezek az x, y, és fnevű 
egyedek léteznek és olyan típusúak, amelyekre az - (értékadás), a 4 (összeadás) és a 0 
(függvényhívás) rendre értelmezettek. 


A C4-4 programokban minden névnek (azonosítónak) van típusa. Ez a típus határozza meg, 
milyen műveleteket lehet végrehajtani a néven (azaz az egyeden, amelyre a név hivatko- 
zik) és ezek a műveletek mit jelentenek. Például a 


float x; // x lebegőpontos változó 
int y — 7; // y egész típusú változó, kezdőértéke 7 
Jloat KinY; // f egész baramétert váró és lebegőpontos számot visszaadó függvény 


deklarációk már értelmessé teszik a fenti példát. Mivel y-t int-ként adtuk meg, értékül lehet 
adni, használni lehet aritmetikai kifejezésekben stb. Másfelől /-et olyan függvényként határoz- 
tuk meg, amelynek egy int paramétere van, így meg lehet hívni a megfelelő paraméterrel. 


Ez a fejezet az alapvető típusokat (44.1.1) és deklarációkat (44.99) mutatja be. A példák csak 
a nyelv tulajdonságait szemléltetik, nem feltétlenül végeznek hasznos dolgokat. A terjedel- 
mesebb és valósághűbb példák a későbbi fejezetekben kerülnek sorra, amikor már többet 
ismertettünk a C4--ból. Ez a fejezet egyszerűen csak azokat az alapelemeket írja le, ame- 
lyekből a C-t programok létrehozhatók. Ismernünk kell ezeket az elemeket, a velük járó 
elnevezéseket és formai követelményeket, ahhoz is, hogy valódi C-- programot készíthes- 
sünk, de főleg azért, hogy el tudjuk olvasni a mások által írt kódot. A többi fejezet megér- 
téséhez azonban nem szükséges teljesen átlátni ennek a fejezetnek minden apró részletét. 
Következésképp az olvasó jobban teszi, ha csak átnézi, hogy megértse a fontosabb fogal- 
makat, és később visszatér, hogy megértse a részleteket, amint szükséges. 
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4.1.1. Alaptípusok 


A C44 rendelkezik azokkal az alaptípusokkal, amelyek megfelelnek a számítógép leggya- 
koribb tárolási egységeinek és adattárolási módszereinek: 


§4.2 Logikai típus (booD 

§4.3 Karaktertípusok (mint a char) 

4.4 Egész típusok (mint az inD 

§4.5 Lebegőpontos típusok (mint a double) 


Továbbá a felhasználó megadhat: 

44.8 felsoroló típusokat adott értékhalmazok jelölésére (enum) 
és létezik a 

4.7 void típus is, melyet az információ hiányának jelzésére használunk. 
Ezekből a típusokból más típusokat is létrehozhatunk. Ezek a következők: 


§5.1 Mutatótípusok (mint az int?) 

§5.2 Tömbtípusok (mint a cAharf )) 

§5.5 Referencia-típusok (mint a doublek) 

§5.7 Adatszerkezetek és osztályok (10. fejeze) 


A logikai, karakter- és egész típusokat együtt integrális típusoknak nevezzük, az integrális 
és lebegőpontos típusokat pedig közösen aritmetikai típusoknak. A felsoroló típusokat és 
az osztályokat (10. fejeze) felhasználói adattípusokként emlegetjük, mert a felhasználónak 
kell azokat meghatároznia; előzetes bevezetés nélkül nem állnak rendelkezésre, mint az 
alaptípusok. A többi típust beépített típusnak nevezzük. 


Az integrális és lebegőpontos típusok többfajta mérettel adottak, lehetővé téve a programo- 
zónak, hogy kiválaszthassa a felhasznált tár nagyságát, a pontosságot, és a számítási érték- 
tartományt (44.06). Azt feltételezzük, hogy a számítógép bájtokat biztosít a karakterek táro- 
lásához, gépi szót az egészek tárolására és az azokkal való számolásra, léteznek alkalmas 
egyedek lebegőpontos számításokhoz és címek számára, hogy hivatkozhassunk ezekre az 
egyedekre. A C-t alaptípusai a mutatókkal és tömbökkel együtt az adott nyelvi megvalósí- 
tástól függetlenül biztosítják ezeket a gépszintű fogalmakat a programozó számára. 


92 Alapok 


A legtöbb programban a logikai értékekhez egyszerűen bool-t használhatunk, karakterek- 
hez char-t, egészekhez int-et, lebegőpontos értékekhez pedig double-t. A többi alaptípus 
hatékonysági és más egyedi célokra használatos, így legjobb azokat elkerülni addig, amíg 
ilyen igények fel nem merülnek, de a régi C és C4- kódok olvasásához ismernünk kell őket. 


4.2. Logikai típusok 


A logikai típusoknak (boo)) két értéke lehet: true vagy false (igaz, illetve hamis). A logikai 
típusokat logikai műveletek eredményének kifejezésére használjuk: 


void f(int a, int b) 
bool b1 - a--b; // - értékadás, -- egyenlőségvizsgálat 


Mesés 


J 


Ha a és b értéke ugyanaz, akkor 57 igaz lesz, máskülönben hamis. 


A bool gyakran használatos olyan függvény visszatérési értékeként, amely valamilyen felté- 
telt ellenőriz (predikátum): 


bool is open(File?); 

bool greater(int a, int b) f return a:b; ) 
Egész számra alakítva a true értéke 7] lesz, a false-é pedig 0. Ugyanígy az egészek is logikai 
típusúvá alakíthatók: a nem nulla egészek true, a 0 false logikai értékké alakulnak: 


bool b -— 7; // bool( 7) igaz, így b igaz 
int i — true; // int(true) értéke 1, így i értéke 1 


Aritmetikai és logikai kifejezésekben a logikai típusok egésszé alakulnak; az aritmetikai és 
logikai egész-műveletek az átalakított értékeken hajtódnak végre. Ha az eredmény vissza- 
alakul logikai típusúvá, a 0 false lesz, a nem nulla egészek pedig true értéket kapnak. 
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void gO 
( 


bool a — true; 
bool b — true; 


bool x - ab; // a4b értéke 2, így x igaz 
booly - alb; // alb értéke 1, így y igaz 
J 


Logikai típusúvá mutatókat is alakíthatunk (4C.6.2.59. A nem nulla mutatók frue, a , nulla 
mutatók" false értékűek lesznek. 


4.3. Karaktertípusok 


A chartípusú változók egy karaktert tárolhatnak az adott nyelvi megvalósítás karakterkész- 
letéből: 


char ch — la; 
A char típus általában 8 bites, így 256 különböző értéket tárolhat. A karakterkészlet jellem- 
zően az ISO-646 egy változata, például ASCII, így a billentyűzeten megjelenő karaktereket 


tartalmazza. Sok probléma származik abból, hogy ezeket a karakterkészleteket csak rész- 
ben szabványosították (4C.3). 


Jelentősen eltérnek azok a karakterkészletek, amelyek természetes nyelveket támogatnak, 
és azok is, amelyek másféleképpen támogatják ugyanazt a természetes nyelvet. Itt azonban 
csak az érdekel minket, hogy ezek a különbségek hogyan befolyásolják a C--- szabályait. 
Ennél fontosabb kérdés, hogyan programozzunk többnyelvű, több karakterkészletes kör- 
nyezetben, ez azonban a könyv keretein túlmutat, bár számos helyen említésre kerül (420.2, 
§21.7, 4C3.3, §D). 


Biztosan feltehető, hogy az adott C$-4-változat karakterkészlete tartalmazza a decimális 
számjegyeket, az angol ábécé 26 betűjét és néhány általános írásjelet. Nem biztos, hogy egy 
8 bites karakterkészletben nincs 127-nél több karakter (néhány karakterkészlet 255 karak- 
tert biztosí), hogy nincs több alfabetikus karakter, mint az angolban (a legtöbb európai 
nyelvben több van), hogy az ábécé betűi összefüggőek (az EBCDIC lyukat hagy az ,i" és 
a ,j" közöt), vagy hogy minden karakter rendelkezésre áll, ami a Ct-4 kód írásához szüksé- 
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ges (néhány nemzeti karakterkészlet nem biztosítja a / ? // I Vv karaktereket, §C.3.1). Ami- 
kor csak lehetséges, nem szabad semmit feltételeznünk az objektumok ábrázolásáról és ez 
az általános szabály a karakterekre is vonatkozik. 

Minden karakternek van egy egész értéke, a ,b"-é például az ASCII karakterkészletben 98. 
Íme egy kis program, amely a begépelt karakter egész értékét mutatja meg: 


sinclude Ciostream: 


int mainŐ 


char c; 
std::cin 525 c; 
std::cout CCVA(2) "" cz c ca!" ! értéke" cz int(c) cz MM; 


j 


Az int(c) jelölés a c karakter egész értékét adja. Az a lehetőség, hogy karaktert egésszé le- 
het alakítani, felvet egy kérdést: a c/aar előjeles vagy előjel nélküli? A 8 bites bájton ábrázolt 
256 értéket úgy lehet értelmezni, mint 0-tól 255-ig vagy -127-től 127-ig terjedő értékeket. 
Sajnos az adott fordítóprogram dönti el, melyiket választja egy sima char esetében (4C.1, 
§C.3.4). A C44 azonban ad két olyan típust, amelyekre a kérdés biztosan megválaszolható: 
a signed char-t (előjeles karakter), amely legalább a -127 és 127 közti értékeket képes tá- 
rolni és az unsigned char (előjel nélküli karakter) típust, amely legalább 0-tól 255-ig tud ér- 
tékeket tárolni. Szerencsére csak a 0-127 tartományon kívüli értékekben lehet különbség 
és a leggyakoribb karakterek a tartományon belül vannak. 


Azok a 0-127tartományon túli értékek, amelyeket egy sima char tárol, nehezen felderíthe- 
tő , hordozhatósági" problémákat okozhatnak. Lásd még a §C.3.4-et arra az esetre, ha több- 
féle char típus szükséges, vagy ha char típusú változókban szeretnénk egészeket tárolni. 


A nagyobb karakterkészletek — például a Unicode -— karaktereinek tárolására a wchar. t áll 
rendelkezésünkre, amely önálló típus. Mérete az adott C-4--változattól függ, de elég nagy 
ahhoz, hogy a szükséges legnagyobb karakterkészletet tárolhassa (lásd §21.7 és §C.3.3). 
A különös név még a C-ből maradt meg. A C-ben a wchar. t egy tybedef(§4.9.7), vagyis tí- 
pus-álnév, nem pedig beépített típus. Az. f toldalék a szabványos typedef-ektől való meg- 
különböztetést segíti. 


Jegyezzük meg, hogy a karaktertípusok integrális típusok (44.1.1), így alkalmazhatóak rájuk 
az aritmetikai és logikai műveletek (46.2) is. 
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4.3.1. Karakterliterálok 

A karakterliterál, melyet gyakran karakterkonstansnak is hívnak, egy egyszeres idézőjelek 
közé zárt karakter, például a"és "0. A karakterliterálok típusa char. Valójában szimbolikus 
konstansok (jelképes állandók), melyek értéke annak a számítógépnek a karakterkészleté- 
ben lévő karakter egész értéke, amin a C-t program fut. Ha például ASCII karakterkészlet- 
tel rendelkező számítógépet használunk, a "0" értéke 48 lesz. A program hordozhatóságát 
javítja, ha decimális jelölés helyett karakterliterálokat használunk. Néhány karakternek szin- 
tén van szabványos neve, ezek a A fordított perjelt használják ún. escape karakterként. Pél- 
dául a Wz az új sort, a 4 pedig a vízszintes tabulátort (behúzásn) jelenti. Az escape karakte- 
rekről részletesebben lásd §C.3.2-t. 

A ,széles" karakterliterálok Z-ab" alakúak, ahol az egyszeres idézőjelek között lévő karakte- 
rek számát és jelentését az adott C4--megvalósítás a wchar. t típushoz igazítja, mivel a szé- 
les karakterliterálok típusa wcAar. t. 


4.4. Egész típusok 


A char-hoz hasonlóan az egész típusok is háromfélék: , sima" int, signed int, és unsigned 
int. Az egészek három méretben adottak: sZort int, , sima" int , illetve long int. Egy long int- 
re lehet sima l/ong-ként hivatkozni. Hasonlóan, a short a short int, az unsigned az unsigned 
int, a signed pedig a signed int szinonimája. 


Az előjel nélküli (unsigned) egész típusok olyan felhasználásra ideálisak, amely úgy kezeli 
a tárat, mint egy bittömböt. Szinte soha nem jó ötlet az előjel nélküli típust használni int he- 
lyett, hogy egy vagy több bitet nyerjünk pozitív egészek tárolásához. Azok a próbálkozá- 
sok, amelyek úgy kísérlik meg biztosítani valamilyen érték nem negatív voltát, hogy a vál- 
tozót unsigned-ként adják meg, általában meghiúsulnak a mögöttes konverziós szabályok 
miatt (4C.6.1, §C.6.2.1. 


A sima char-ral ellentétben a sima int-ek mindig előjelesek. A signed int típusok csak vilá- 
gosabban kifejezett szinonimái a nekik megfelelő sima int típusoknak. 


96 Alapok 


4.4.1. Egész literálok 


Az egész literálok négyféle alakban fordulnak elő: decimális, oktális, hexadecimális és 
karakterliterálként. A decimális literálok a leginkább használatosak és úgy néznek ki, ahogy 
elvárjuk tőlük: 


7 1234 976  12345678901234567890 


A fordítóprogramnak figyelmeztetnie kell olyan literálok esetében, amelyek túl hosszúak az 
ábrázoláshoz. A nullával kezdődő és x-szel folytatódó (020) literálok hexadecimális (16-os 
számrendszerbeli) számok. Ha a literál nullával kezdődik és számjeggyel folytatódik, oktá- 
lis (8-as számrendszerbeli) számról van szó: 


decimális: 2 63 83 
oktális: (0) 02 077 0123 
hexadecimális: 0x0O 0x2 0x3f 0x53 


Az a, b, c, d, eés fbetűk, illetve nagybetűs megfelelőik rendre 70-et, 77-et, 72-t, 13-at, 14 
et és 15-öt jelentenek. Az oktális és hexadecimális jelölés leginkább bitminták kifejezésénél 
hasznos. Meglepetéseket okozhat, ha ezekkel a jelölésekkel valódi számokat fejezünk ki. 
Egy olyan gépen például, ahol az int egy kettes komplemensű 16 bites egészként van áb- 
rázolva, Oxfjffa -1 negatív decimális szám lesz. Ha több bitet használtunk volna az egész 
ábrázolására, akkor ez 65 535 lett volna. 


Az Uutótag használatával előjel nélküli (unsigned) literálokat adhatunk meg. Hasonlóan, az 
L utótag használatos a /ong literálokhoz. Például 3 egy int, 3 egy unsigned int és 3L egy 
long int. Ha nincs megadva utótag, a fordító egy olyan egész literált ad, amelynek típusa 
megfelel az értéknek és a megvalósítás egész-méreteinek (4C.4). 


Jó ötlet korlátozni a nem maguktól értetődő állandók használatát néhány, megjegyzésekkel 
megfelelően ellátott const (§5.4) vagy felsoroló típusú (44.8) kezdeti értékadására. 


4.5. Lebegőpontos típusok 


A lebegőpontos típusok lebegőpontos (valós) számokat ábrázolnak. Az egészekhez hason- 
lóan ezek is háromfajta méretűek lehetnek: //oat (egyszeres pontosságú), double (kétszeres 
pontosságú), és long double (kiterjesztett pontosságú). 
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Az egyszeres, kétszeres és kiterjesztett pontosság pontos jelentése az adott C---változattól 
függ. A megfelelő pontosság kiválasztása egy olyan problémánál, ahol fontos a választás, 
a lebegőpontos számítások mély megértését követeli meg. Ha nem értünk a lebegőpontos 
aritmetikához, kérjünk tanácsot, szánjunk időt a megtanulására, vagy használjunk double-t 
és reméljük a legjobbakat. 


4.5.1. Lebegőpontos literálok 


Alapértelmezés szerint a lebegőpontos literálok double típusúak. A fordítónak itt is figyel- 
meztetnie kell, ha a lebegőpontos literálok az ábrázoláshoz képest túl nagyok. Íme néhány 
lebegőpontos literál: 


1.23 .23 0.23 1. 10 1.2e10 1.23e€-15 


Jegyezzük meg, hogy szóköz nem fordulhat elő egy lebegőpontos literál közepén. 
A 65.43 e-21 például nem lebegőpontos literál, hanem négy különálló nyelvi egység (ami 
formai hibát okoz): 


65.43 e - 21 


Ha float típusú lebegőpontos literált akarunk megadni, akkor azt az fvagy F utótag haszná- 
latával tehetjük meg: 


3.14159265f  2.Of 2.997925F 2.9e-3f 


Ha long doubletípusú lebegőpontos literált szeretnénk megadni, használjuk az /vagy L utó- 
tagot: 


3.14159265L 2.0L 2.997925I  2.9e-3I 


4.6. Méretek 


A C44 alaptípusainak néhány jellemzője, mint például az int mérete, a Ct- adott megvaló- 
sításától függ (§C.2). Rámutatok ezekre a függőségekre és gyakran ajánlom, hogy kerüljük 
őket vagy tegyünk lépéseket annak érdekében, hogy hatásukat csökkentsük. Miért kellene 
ezzel foglalkozni? Azok, akik különböző rendszereken programoznak vagy többféle fordí- 
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tót használnak, kénytelenek törődni ezzel, mert ha nem tennék, rákényszerülnének arra, 
hogy időt pazaroljanak nehezen megfogható programhibák megtalálására és kijavítására. 
Azok, akik azt állítják, hogy nem érdekli őket a hordozhatóság, általában azért teszik ezt, 
mert csak egy rendszert használnak és úgy érzik, megengedhetik maguknak azt a hozzáál- 
lást, miszerint , a nyelv az, amit a fordítóm megvalósít". Ez beszűkült látásmód. Ha egy prog- 
ram sikeres, akkor valószínű, hogy átviszik más rendszerre, és valakinek meg kell találnia 
és ki kell javítania a megvalósítás sajátosságaiból adódó problémákat. A programokat to- 
vábbá gyakran újra kell fordítani más fordítókkal ugyanarra a rendszerre és még a kedvenc 
fordítónk későbbi változata is másképpen csinálhat néhány dolgot, mint a mostani. Sokkal 
egyszerűbb ismerni és korlátozni az adott fordító használatának hatását, amikor egy prog- 
ramot megírnunk, mint megpróbálni később kibogozni a problémát. 


A megvalósításból eredő nyelvi sajátosságok hatását viszonylag könnyű korlátozni, a rend- 
szerfüggő könyvtárakét azonban sokkal nehezebb. Az egyik módszer az lehet, hogy lehe- 
tőleg csak a standard könyvtár elemeit használjuk. 


Annak, hogy több egész, több előjel nélküli, és több lebegőpontos típus van, az az oka, 
hogy ez lehetőséget ad a programozónak, hogy a hardver jellemzőit megfelelően kihasz- 
nálhassa. Sok gépen jelentős különbségek vannak a memóriaigényben, a memória hozzá- 
férési idejében, és a többfajta alaptípussal való számolási sebességben. Ha ismerjük a gé- 
pet, általában könnyen kiválaszthatjuk például a megfelelő egész típust egy adott változó 
számára, igazán hordozható kódot írni azonban sokkal nehezebb. 


A C44 objektumainak mérete mindig a char méretének többszöröse, így a char mérete 1. 
Egy objektum méretét a sizeof operátorral kaphatjuk meg (46.29. Az alaptípusok méretére 
vonatkozóan a következők garantáltak: 


1 z sizeof(char) S sizeof(shor?) S sizeof(in) S sizeoftlong) 
1 s sizeof(bool) . sizeof(long) 

sizeof(char) S sizeof(wchar. 1) S sizeof(long) 

sizeofffloan s sizeof(double) S sizeof(long double) 
sizeof(N) z sizeof(signed N) z sizeof(unsigned N) 


A fentiekben NlIlehet char, short int, int vagy long int, továbbá biztosított, hogy a char leg- 
alább 8, a short legalább 16, a long pedig legalább 32 bites. A char a gép karakterkészleté- 
ből egy karaktert tárolhat. Az alábbi ábra az alaptípusok egy lehetséges halmazát és egy 
minta-karakterláncot mutat: 
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tal 
char: a 


bool: [1] 


short: 756 











hat 100000000 











int": gci 








double: 1234567e34 





char[141: Hello, world! VO 











Ugyanilyen méretarányban (0,5 cm egy báj9) egy megabájt memória körülbelül öt kilomé- 
ternyire lógna ki a jobb oldalon. 


A char típust az adott nyelvi változatnak úgy kell megválasztania, hogy a karakterek tárolá- 
sára és kezelésére egy adott számítógépen a legmegfelelőbb legyen; ez jellemzően egy 8 bi- 
tes bájt. Hasonlóan, az inttípusnak a legmegfelelőbbnek kell lennie az egészek tárolására és 
kezelésére; ez általában egy 4 bájtos (32 bites) gépi szó. Nem bölcs dolog többet feltételez- 
ni. Például vannak olyan gépek, ahol a char 32 bites. Ha szükségünk van rá, az adott C4--- 
változat egyedi tulajdonságait megtalálhatjuk a climitsz fejállományban (422.2). Például: 


finclude climitsz 
finclude Ciostream: 


int mainŐ 


j std::cout 2 "A legnagyobb lebegőpontos szám -- " 22 std::numeric limitszfloat:::maxO 
za ", a char előjeles —— " c£ std::numeric limitszchar:::is signed cz Mi; 
J 
Az alaptípusok értékadásokban és kifejezésekben szabadon párosíthatók. Ahol lehetséges, 
az értékek úgy alakítódnak át, hogy ne legyen adatvesztés (4C.0). 


Ha vérték pontosan ábrázolható egy 7Ttípusú változóban, akkor vérték 7típusúvá alakítá- 
sa megőrzi az értéket és nincs probléma. Legjobb, ha elkerüljük azokat az eseteket, amikor 
a konverziók nem értékőrzők (§C.6.2.0). 


Nagyobb programok készítéséhez az automatikus konverziókat részletesebben meg kell ér- 
tenünk, főleg azért, hogy képesek legyünk értelmezni a mások által írt kódot, a következő 
fejezetek olvasásához ugyanakkor ez nem szükséges. 
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4.7. Void 


A void formája alapján alaptípus, de csak egy bonyolultabb típus részeként lehet használni; 
nincsenek void típusú objektumok. Vagy arra használjuk, hogy meghatározzuk, hogy egy 
függvény nem ad vissza értéket, vagy akkor, amikor egy mutató ismeretlen típusú objek- 
tumra mutat: 


void Xx; // hiba: nincsenek void objektumok 
void fO; // az f függvény nem ad vissza értéket (§7.3) 
void? pu; // ismeretlen típusú objektumra hivatkozó mutató (§5.6) 


Amikor egy függvényt bevezetünk, meg kell határozni visszatérési értékének típusát is. Lo- 
gikailag elvárható lenne, hogy a visszatérési típus elhagyásával jelezzük, a függvény nem 
ad vissza értéket. Ez viszont a nyelvtant ( A" függelék) kevésbé szabályossá tenné és ütköz- 
ne a C-beli gyakorlattal. Következésképpen a void ,látszólagos visszatérési típus"-ként 
használatos, annak jelölésére, hogy a függvény nem ad vissza értéket. 


4.8. Felsoroló típusok 


A felsoroló típus (enumeration) olyan típus, amely felhasználó által meghatározott értéke- 
ket tartalmaz. Meghatározása után az egész típushoz hasonlóan használható. A felsoroló tí- 
pusok tagjaiként névvel rendelkező egész konstansokat adhatunk meg. Az alábbi kód pél- 
dául három egész állandót ad meg — ezeket felsoroló konstansoknak nevezzük - és értéke- 
ket rendel hozzájuk: 


enum f ASM, AUTO, BREAK ?; 


Alapértelmezés szerint az állandók 0-tól növekvően kapnak értékeket, így ASM--0, 
AUTO--1, BREAK-72. A felsoroló típusnak lehet neve is: 


enum keyword f( ASM, AUTO, BREAK ?; 


Minden felsorolás önálló típus. A felsoroló konstansok típusa a felsorolási típus lesz. 
Az AUTO például keyword típusú. 
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Ha keyword típusú változót adunk meg sima int helyett, mind a felhasználónak, mind a for- 
dítónak utalunk a változó tervezett használatára: 


void (keyword key) 
í 
switch (key) ( 
case ASM: 
// valamit csinálunk 
break; 
case BREAK: 
// valamit csinálunk 
break; 
A 
J 


A fordító figyelmeztetést adhat, mert a három keyword típusú értékből csak kettőt kezeltünk. 


A felsoroló konstans a kezdeti értékadáskor integrális típusú (§44.1.1) konstans kifejezéssel 
(§C.5.) is megadható. A felsoroló típus értékhalmaza összes tagjának értékét tartalmazza, 
felkerekítve a 2 legközelebbi, azoknál nagyobb hatványánál eggyel kisebb értékig. Ha 
a legkisebb felsoroló konstans nem negatív, az értékhalmaz 0-val kezdődik, ha negatív, a 2 
legközelebbi, a tagoknál kisebb negatív hatványával. Ez a szabály azt a legkisebb bitmezőt 
adja meg, amely tartalmazhatja a felsoroló konstansok értékét. Például: 


enum el ( dark, light ) ; // tartomány: O:1 
enum e2fa-3 b- 93; // tartomány: 0:15 
enum e3 ( min -— -10, max - 1000000 7; // tartomány: -1048576:1048575 


Egy integrális típus értékét meghatározott módon felsoroló típusúvá alakíthatjuk. Ha az ér- 
ték nem esik a felsoroló típus értékhalmazába, a konverzió eredménye nem meghatározott: 


enum flag ( x-1, y-2, z-4, e-8 ); // tartomány: O:15 


flag fi — 5; // típushiba: 5 nem flag típusú 

flag f2 - flagO09; // rendben: flagC5) flag típusú és annak tartományán belüli 
flag f3 - flag(z IE); // rendben: flagC(12) flag típusú és annak tartományán belüli 
flag Já - flag(999; // meghatározatlan: 99 nem esik a flag tartományán belülre 


Az utolsó értékadás mutatja, miért nincs automatikus konverzió egészről felsoroló típusra; 
a legtöbb egész érték ugyanis nem ábrázolható egy adott felsoroló típusban. 
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A felsoroló típusok értékhalmazának fogalma különbözik a Pascal nyelvcsaládba tartozó 
nyelvek felsoroló típusainak fogalmától. A C-ben és a Ct4-ban azonban hosszú hagyomá- 
nya van azoknak a bitkezelő műveleteknek, amelyek arra építenek, hogy a felsoroló típu- 
sok tagjain kívüli értékek jól körülhatároltak. 


A felsoroló típusok sizeoffja egy olyan integrális típus sizeof-ja, amely képes a felsoroló tí- 
pus értékhalmazát tárolni és nem nagyobb sizeof(inD-nél, hiszen akkor nem lehetne int- 
ként vagy unsigned int-ként ábrázolni. Például sizeof(e1) lehet 7 vagy talán 4, de nem lehet 
8 egy olyan gépen, ahol sizeof(int)——4. 


Alapértelmezés szerint a felsoroló típusok aritmetikai műveletek esetében egésszé alakítód- 
nak (§6.2). A felsoroló típus felhasználói típus, így a felhasználók a felsorolásra saját műve- 
leteket adhatnak meg, például a -4- és cc operátorokkal (411.2.3). 


4.9. Deklarációk 


A C34 programokban a neveket (azonosítókat) használat előtt be kell vezetnünk, azaz meg 
kell határoznunk típusukat, hogy megmondjuk a fordítónak, a név miféle egyedre hivatko- 
zik. A deklarációk sokféleségét a következő példák szemléltetik: 


char ch; 

string s; 

int count — 1; 

const double pi - 3.1415926535897932395; 
extern int error. number; 


char? name - "Natasa"; 
char? season[ ] - ( "tavasz", "nyár", "ősz", "tél" ); 


struct Date f int d, m, y; ?; 

int day(Date" p) f return p-2d; ) 

double sgrt(double); 

templatexclass T- T abs(T a) f return axo ? -a : a; ) 


typedef complexsshort: Point; 

struct User; 

enum Beer ( GCarlisberg, Tuborg, Thor ?; 
namespace NS f int a; ) 
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Amint a példákból látható, a deklaráció többet is jelenthet annál, mint hogy egyszerűen 
egy nevet kapcsol össze a név típusával. A fenti deklarációk többsége definíció is, azaz 
meg is határozza azt az egyedet, amelyre a név hivatkozik. A c/A esetében például ez az 
egyed a megfelelő memóriaterület, amelyet változóként használunk (vagyis ezt a memó- 
riaterületet fogjuk lefoglalni), a day-nél a meghatározott függvény, a pi állandónál 
a 3.1415926535897932385 érték, a Date-nél egy új típus. A Point esetében az egyed 
a complexcshort: típus, így a Point a complexcshort: szinonimája lesz. A fenti deklaráci- 
ók közül csak a 


double sgrt(double); 
extern int error. number; 
struct User; 


deklarációk nem definíciók is egyben: azaz máshol kell definiálni (meghatározni) azokat az 
egyedeket, amelyekre hivatkoznak. Az sgrt függvény kódját (törzsét) más deklarációkkal 
kell meghatározni, az int típusú error. number változó számára az error. number egy má- 


kell megadnia, hogy a típus hogy nézzen ki. Például: 


double sgrt(double d) €/ ... "/) 
int error. number — 1; 


struct User £/£ ... "7 ); 


A C4t4 programokban minden név számára mindig pontosan egy definíció (meghatározás) 
létezhet (az sincilude hatásait lásd §9.2.3-ban). Ugyanakkor a nevet többször is 
deklarálhatunk (bevezethetjük). Egy egyed minden deklarációja meg kell, hogy egyezzen 
a hivatkozott egyed típusában. Így a következő részletben két hiba van: 


int count; 
int count; // hiba: újbóli definíció 


extern int error. number; 
extern short error. number; // hiba: nem megfelelő típus 


A következőben viszont egy sincs (az extern használatáról lásd 49.29: 


extern int error. number; 
extern int error. number; 
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Néhány definíció valamilyen , értéket" is meghatároz a megadott egyedeknek: 


struct Date f int d, m, y; ?; 

typedef complexsshort: Point; 

int day(Date" p) f return p-2d; ) 

const double pi - 3.1415926535897932395; 


Típusok, sablonok, függvények és állandók esetében ez az ,érték" nem változik. Nem 
konstans adattípusok esetében a kezdeti értéket később módosíthatjuk: 


void JO 
( 


int count — 1; 

char" name -— "Bjarne"; 
VARD 

count — 2; 

name - "Marian"; 


A definíciók közül csak az alábbi nem határoz meg értéket: 


char ch; 
string s; 


(Arról, hogy hogyan és mikor kap egy változó alapértelmezett értéket, lásd §4.9.5-öt és 
§10.4.2-t.) Minden deklaráció, amely értéket határoz meg, egyben definíciónak is minősül. 


4.9.1. A deklarációk szerkezete 


A deklarációk négy részből állnak: egy nem kötelező minősítőből, egy alaptípusból, egy 


deklarátorból, és egy — szintén nem kötelező — kezdőérték-adó kifejezésből. A függvény- és 
névtér-meghatározásokat kivéve a deklaráció pontosvesszőre végződik: 


char? kings[ ] - f "Antigónusz", "Szeleukusz", "Ptolemaiosz" ); 


Itt az alaptípus char, a deklarátor a "kings/ /, a kezdőérték-adó rész pedig az —f...). 

A minősítő (specifier) egy kulcsszó, mint a virtual (§2.5.5, §12.2.6) és az extern (§9.2), és 
a bevezetett elem néhány, nem a típusra jellemző tulajdonságát határozza meg. A deklará- 
tor (declarator) egy névből és néhány nem kötelező operátorból áll. A leggyakoribb dekla- 
rátor-operátorok a következők (VA.7. DD: 
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si mutató előtag 
tconst konstans mutató előtag 
k referencia előtag 
74 tömb utótag 
oO függvény utótag 


Használatuk egyszerű lenne, ha mindegyikük előtagként (prefix) vagy mindegyikük utótag- 
ként (postfix) használt operátor volna. A ?, a / Jés a 0 operátorokat azonban arra tervez- 
ték, hogy kifejezésekben is használhatók legyenek (46.2), így a " előtag-, a /Jés a 0 pedig 
utótag operátorok. Az utótagként használt operátorok több megkötéssel járnak, mint az elő- 
tagként használtak. Következésképpen a "kings/ / egy valamire hivatkozó mutatókból álló 
vektor, és zárójeleket kell használnunk, ha olyasmit akarunk kifejezni, mint , . .. függvényre 
hivatkozó mutató" (lásd az §5.1 példáit). Teljes részletességgel lásd a nyelvtant az , A" füg- 
gelékben. 


Jegyezzük meg, hogy a típus nem hagyható el a deklarációból: 


const c — 7; // hiba: nincs típus 

et(int a, int b) f return (aPb) ? a : b; ) // hiba: nincs visszatérési típus 
unsigned ui; // rendben: tunsigned! jelentése tunsigned int" 

long li; // rendben: long! jelentése long int" 


A szabványos C--- ebben eltér a C és a C-t régebbi változataitól, amelyek megengedték az 
első két példát, azt feltételezve, hogy a típus int, ha nincs típus megadva (§B.2). Ez az , imp- 
licit inf" szabály sok félreértés és nehezen megfogható hiba forrása volt. 


4.9.2. Több név bevezetése 


Egyetlen deklarációban több nevet is megadhatunk. A deklaráció ekkor vesszővel elválasz- 
tott deklarációk listáját tartalmazza. Két egészet például így vezethetünk be: 


int x, y; // int x és int y; 
, MJ 


Jegyezzük meg, hogy az operátorok csak egyes nevekre vonatkoznak, az ugyanabban 
a deklarációban szereplő további nevekre nem: 


intt p, y; // int? p és int y, NEM int" y 
int x, "g; // int x és int? g 
int vl10], "pu; // int 10] és int" pv 


A fentihez hasonló szerkezetek rontják a program olvashatóságát, ezért kerülendők. 
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4.9.3. Nevek 


A név (azonosító) betűk és számok sorozatából áll. Az első karakternek betűnek kell len- 
nie. Az (aláhúzás) karaktert betűnek tekintjük. A C-t nem korlátozza a névben használ- 
ható karakterek számát. A fordítóprogram írója azonban a megvalósítás egyes részeire nincs 
befolyással (konkrétan a szerkesztőprogramra, a linker-re), ez pedig határokat szab. 
Néhány futási idejű környezet ugyancsak szükségessé teszi, hogy kibővítsük vagy megszo- 
rítsuk az azonosítóban elfogadható karakterkészletet. A bővítések (például a $ engedélye- 
zése egy névben) nem hordozható programokat eredményeznek. A C-- kulcsszavai (, A" 


függelék), mint a new és az int, nem használhatók felhasználói egyedek neveként. Példák 


a nevekre: 
hello ez egy szokatlanul hosszú név 
DEFINED foo bDAr u name  LoPatko 
varo var1 CLASS . class 


És néhány példa olyan karaktersorozatokra, amelyek nem használhatók azonosítóként: 


012 egy bolond $sys class 3var 
fizetes.esedekes — foo-bar .name if 


Az aláhúzással kezdődő nevek a nyelvi megvalósítás és a futási idejű környezet egyedi esz- 
közei számára vannak fenntartva, így ezeket nem szabadna használni alkalmazói progra- 
mokban. 


Amikor a fordító olvassa a programot, mindig a leghosszabb olyan sorozatot keresi, amely 
kiadhat egy nevet. Így a var10 és nem a var név (amit a 10-es szám követ). Hasonlóan, az 
elseifis egy név, nem pedig az else, amit az ifkulcsszó követ. 


A kis- és nagybetűket a nyelv megkülönbözteti, így a Count és a count különböző nevek, 
de nem bölcs dolog olyan neveket választani, amelyek csak a kezdőbetűben térnek el. 
A legjobb elkerülni azokat a neveket, amelyek csak kicsit különböznek. Például a nagybe- 
tűs o (O) és a nulla (0) nehezen megkülönböztethető, a kis L (D és az egyes ( D szintén. Kö- 
vetkezésképpen azonosítónak a /O, JO, 17 és Il nem szerencsés választás. 


A nagy hatókörű nevek lehetőleg hosszúak és érthetőek legyenek, mint vector, 
Window with border, és Department number. A kód viszont érthetőbb lesz, ha a kis ható- 
körben használt neveknek rövid, hagyományos stílusú nevük van, mint x, iés p. Az osztályok 
(10. fejeze) és a névterek (§8.2) használhatók arra, hogy a hatókörök kicsik maradjanak. 
Hasznos dolog viszonylag rövidnek hagyni a gyakran használt neveket, az igazán hosszúakat 
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pedig megtartani a kevésbé gyakran használatos egyedeknek. Válasszuk meg úgy a neveket, 
hogy az egyed jelentésére és ne annak megvalósítására utaljanak. A bhone book (telefon- 
könyv) például jobb, mint a number. list (számok listája), még akkor is, ha a telefonszámokat 
listában (§3.7) tároljuk. A jó nevek megválasztása is egyfajta művészet. 


Próbáljunk következetes elnevezési stílust fenntartani. Például írjuk nagy kezdőbetűvel 
a nem standard könyvtárbeli felhasználói típusokat és kisbetűvel azokat a neveket, amelyek 
nem típusnevek (például Shape és current token). Továbbá használjunk csupa nagybetűt 
makrók esetében (ha makrókat kell használnunk, például HACK) és használjunk aláhúzást, 
ha az azonosítóban szét akarjuk választani a szavakat. Akárhogy is, nehéz elérni a követke- 
zetességet, mivel a programokat általában különböző forrásokból vett részletek alkotják és 


számos különböző ésszerű stílus használatos bennük. Legyünk következetesek a rövidíté- 
sek és betűszavak használatában is. 


4.9.4. Hatókörök 


A deklaráció a megadott nevet egy hatókörbe (scope) vezeti be, azaz a nevet csak a prog- 
ramszöveg meghatározott részében lehet használni. A függvényeken belül megadott nevek 
esetében (ezeket gyakran lokális vagy helyi névnek hívjuk) ez a hatókör a deklaráció helyé- 
től annak a blokknak a végéig tart, amelyben a deklaráció szerepel. A blokk olyan kódrész, 
amelyet a / ) kapcsos zárójelek határolnak. 


Egy nevet giobálisnak nevezünk, ha függvényen, osztályon (10. fejezet) vagy névtéren 
(48.29) kívül bevezetett. A globális nevek hatóköre a bevezetés pontjától annak a fájlnak 
a végéig terjed, amelyben a deklaráció szerepel. A blokkokban szereplő névdeklarációk 
a körülvevő blokkban lévő deklarációkat és a globális neveket elfedhetik, azaz egy nevet 
újra meg lehet adni úgy, hogy egy másik egyedre hivatkozzon egy blokkon belül. A blokk- 


ból való kilépés után a név visszanyeri előző jelentését: 


int Xx; // globális x 

void JO 

t 
int Xx; // a lokális x elfedi a globális x-et 
x 7 1; // értékadás a lokális x-nek 
( 


intx; —— // elfedi az első lokális x-et 
x7- 2 / értékadás a második lokális x-nek 
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x53; // értékadás az első lokális x-nek 


intt p - £Xx; // a globális x címének felhasználása 


A nevek elfedése elkerülhetetlen nagy programok írásakor. A kódot olvasónak azonban 
könnyen elkerüli a figyelmét, hogy egy név többször szerepel. Mivel az ilyen hibák viszony- 
lag ritkán fordulnak elő, nagyon nehezen lehet azokat megtalálni. Következésképpen 
a névelfedések számát a lehető legkisebbre kell csökkenteni. Ha valaki olyan neveket hasz- 
nál globális változóként vagy egy hosszabb függvény lokális változójaként, mint i és x, ak- 
kor maga keresi a bajt. 


Az elfedett globális nevekre a :: hatókörjelző használatával hivatkozhatunk: 


int X; 

void 120 

( 
int x — 1; // a globális x elfedése 
sg e2 // értékadás a globális x-nek 
x-2 // értékadás a lokális x-nek 
Ma. 


j 


Elfedett lokális név használatára nincs mód. 


a kezdeti értéklek)et megadó rész előtt. Ez azt jelenti, hogy egy nevet saját kezdőértékének 
meghatározására is használhatunk: 


int X; 


void 130 
( 


intx-x; — // perverz: kezdeti értékadás x-nek saját maga (nem meghatározott) értékével 


j 


Ez nem tiltott, csak butaság. Egy jó fordítóprogram figyelmeztetést ad, ha egy változót az- 
előtt használunk, mielőtt értékét beállítottuk volna (ásd §5.919]. 
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Egy névvel egy blokkban két különböző objektumra a :: operátor használata nélkül is hi- 
vatkozhatunk: 


intx - 11; 
void [40 // perverz: 
( 
int y— Xx; // a globális x felhasználása, y — 11 
int x - 22; 
Y7X // a lokális x felhasználása, y - 22 
j 


A függvényparaméterek neveit úgy tekintjük, mint ha a függvény legkülső blokkjában len- 
nének megadva, így az alábbi hibás, mert x-et ugyanabban a hatókörben kétszer adtuk 
meg: 


void fCint x) 


f 
int Xx; // hiba 
j 


Ilyen hiba gyakran előfordul, érdemes figyelnünk rá. 


4.9.5. Kezdeti értékadás 


Ha egy objektumhoz kezdőérték-adó kifejezést adunk meg, akkor ez határozza meg az ob- 
jektum kezdeti értékét. Ha nincs megadva ilyen, a globális (44.9.4), névtér (48.29), vagy helyi 
statikus objektumok (§7.1.2, §10.2.4) (melyeket együttesen statikus objektumoknak neve- 
zünk) a megfelelő típus O értékét kapják kezdőértékül: 


int a; // jelentése "int a — O;" 
double d; // jelentése "double d — 0.O;" 


A lokális változóknak (ezeket néha automatikus objektumoknak nevezzük) és a szabad tár- 
ban létrehozott objektumoknak (dinamikus vagy ,heap" objektumok) alapértelmezés sze- 
rint nincs kezdőértékük: 


void JO 
í 


intx; —— // x értéke nem meghatározott 
208 
J 
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A tömbök és struktúrák tagjai alapértelmezés szerint kapnak kezdőértéket, függetlenül at- 
tól, hogy az adott szerkezet statikus-e vagy sem. A felhasználói típusokhoz magunk is meg- 


adhatunk alapértelmezett kezdőértéket (410.4.2). 


A bonyolultabb objektumoknak egynél több értékre van szükségük a kezdeti értékadáshoz. 
A tömbök és struktúrák C típusú feltöltésekor (45.2.1, §5.7) ezt egy / ? zárójelek által hatá- 
rolt listával érhetjük el. A konstruktorral rendelkező felhasználói típusoknál a függvény stí- 
lusú paraméterlisták használatosak (42.5.2, §10.2.39. Jegyezzük meg, hogy a deklarációkban 
szereplő üres zárójelek jelentése mindig , függvény": 


inta(l]-( 1, 23; // tömb kezdeti értékadása 
Point z(1,29; // függvény stílusú kezdeti értékadás (konstruktorral) 
int JO; // függvény-deklaráció 


4.9.6. Objektumok és balértékek 


Névvel nem rendelkező , változókat" is lefoglalhatunk és használhatunk, és értéket is adha- 
tunk nekik furcsa kifejezésekkel (pl. "pla- 10/-7). Következésképp el kellene neveznünk 
azt, hogy ,valami a memóriában". Ez az objektum legegyszerűbb és legalapvetőbb fogalma. 
Azaz, az objektum egy folytonos tárterület; a bal oldali érték (, balérték") pedig egy olyan 
kifejezés, amely egy objektumra hivatkozik. A balérték (/value) szót eredetileg arra alkot- 
ták, hogy a következőt jelentse: , valami, ami egy értékadás bal oldalán szerepelhet". Nem 
minden balérték lehet azonban az értékadás bal oldalán, egy balérték hivatkozhat állandóra 
(consD is (45.59. A nem const-ként megadott balértéket szokás módosítható balértéknek 
(modifiable Ivalue) is nevezni. Az objektumnak ezt az egyszerű és alacsony szintű fogalmát 
nem szabad összetéveszteni az osztályobjektumok és többalakú (polimorf típusú) objektu- 
mok (§15.4.3) fogalmával. 


Hacsak a programozó másképp nem rendelkezik (§7.1.2, §10.4.8), egy függvényben beve- 
zetett változó akkor jön létre, amikor definíciójához érkezünk, és akkor szűnik meg, ami- 
kor a neve a hatókörön kívülre kerül (410.4.4). Az ilyen objektumokat automatikus objek- 
tumoknak nevezzük. A globális és névtér-hatókörben bevezetett objektumok és a függvé- 
nyekben vagy osztályokban megadott szatic objektumok (csak) egyszer jönnek létre és 
kapnak kezdeti értéket, és a program befejeztéig , élnek"(10.4.9). Az ilyen objektumokat 
statikus objektumoknak nevezzük. A tömbelemeknek és a nem statikus struktúrák vagy 
osztályok tagjainak az élettartamát az az objektum határozza meg, amelynek részei. A new 
és delete operátorokkal olyan objektumok hozhatók létre, amelyek élettartama közvetlenül 
szabályozható (46.2.0). 
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4.9.7. Typedef 


Az a deklaráció, amit a tybedef kulcsszó előz meg, a típus számára új nevet hoz létre, nem 
egy adott típusú változót: 


typedef char?" Pchar; 
Pchar p1, p2; // p1 és p2 típusa char" 
char?" p3 - pI; 


Az így megadott, gyakran typedef-nek C(áltípus) nevezett név kényelmes rövidítés lehet egy 
nehezen használható név helyett. Például az unsigned char túlságosan hosszú az igazán 
gyakori használatra, ezért megadhatjuk a szinonimáját, az uchar-t: 


typedef unsigned char uchar; 


A typedef másik használata az, hogy egy típushoz való közvetlen hozzáférést egy helyre 
korlátozunk: 


typedef int int32; 
typedef short int16; 


Ha most az int32-t használjuk, amikor egy viszonylag nagy egészre van szükségünk, prog- 
ramunkat átvihetjük egy olyan gépre, ahol a sizeof(int) 2-vel egyenlő, úgy, hogy a kódban 
egyszer szereplő int32-t most másképp határozzuk meg: 


typedef long int32; 


Végezetül, a typedef-ek inkább más típusok szinonimái, mint önálló típusok. Következés- 
képpen a tybedef-ek szabadon felcserélhetők azokkal a típusokkal, melyeknek szinonimái. 
Azok, akik ugyanolyan jelentéssel vagy ábrázolással rendelkező önálló típusokat szeretné- 
nek, használják a felsoroló típusokat (§44.8) vagy az osztályokat (10. fejezet. 
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4.10. Tanácsok 


[1] 
[2] 


[3] 
[4] 


[5] 
[6] 
[7] 
[8] 
[9] 
[10] 


[11] 


[12] 
[13] 


[14] 


[15] 
[16] 


[17] 


[18] 
[19] 


[20] 
[21] 


A hatókörök legyenek kicsik. 44.9.4. 

Ne használjuk ugyanazt a nevet egy hatókörben és az azt körülvevő hatókörben 
is. §4.9.2. 

Deklarációnként (csak) egy nevet adjunk meg. §4.9.3. 

A gyakori és helyi nevek legyenek rövidek, a nem helyi és ritkán használt ne- 
vek hosszabbak. §4.9.3. 

Kerüljük a hasonlónak látszó neveket. §4.9.3. 

Elnevezési stílusunk legyen következetes. §4.9.3. 

Figyeljünk arra, hogy a névválasztás inkább a jelentésre, mintsem a megvalósí- 
tásra utaljon. §4.9.3. 

Ha a beépített típus, amelyet egy érték ábrázolására használunk, megváltozhat, 
használjunk typedef-et, így a típus számára beszédes nevet adhatunk. §4.9.7 

A typedef-ekkel típusok szinonimáit adjuk meg; új típusok definiálására használ- 
junk felsoroló típusokat és osztályokat. §44.9.7. 

Emlékezzünk arra, hogy minden deklarációban szükséges a típus megadása 
(nincs , implicit int"). §4.9.1. 

Kerüljük a karakterek számértékével kapcsolatos szükségtelen feltételezéseket. 
§4.3.1, §C.6.2.1. 

Kerüljük az egészek méretével kapcsolatos szükségtelen feltételezéseket. 4.6. 
Kerüljük a szükségtelen feltételezéseket a lebegőpontos típusok értékkészleté- 
vel kapcsolatban is. § 4.6. 

Részesítsük előnyben a sima int-et a short int-tel vagy a long int-tel szemben. 
§4.6. 

Részesítsük előnyben a double-t a float-tal vagy a long double-lal szemben. §4.5. 
Részesítsük előnyben a sima char-t a signed char-ral és az unsigned char-ral 
szemben. §C.3.4. 

Kerüljük az objektumok méretével kapcsolatos szükségtelen feltételezéseket. 
§4.6. 

Kerüljük az előjel nélküli aritmetikát. §44.4. 

Legyünk óvatosak az előjelesről előjel nélkülire és unsigned-ról signed-ra való 
átalakítással. §C.6.2.6. 

Legyünk óvatosak a lebegőpontos típusról egészre való átalakítással. § C.6.2.6. 
Legyünk óvatosak a kisebb típusokra való átalakításokkal (például int-ről char-ra). 


§ C.6.2.6. 
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4.11. Gyakorlatok 


1. C2) Futtassuk le a , Helló, világ! programot (§3.2)9. Ha a program fordítása nem 
úgy sikerül, ahogy kellene, olvassuk el §B.3.1-et. 

2. C1) §4.9 minden deklarációjára végezzük el a következőket: ha a deklaráció 
nem definíció, írjunk hozzá definíciót. Ha a deklaráció definíció is, írjunk olyan 
deklarációt, ami nem az. 

3. (1.5) Írjunk programot, amely kiírja az alaptípusok, néhány szabadon választott 
mutatótípus és néhány szabadon választott felsoroló típus méretét. Használjuk 
a sizeof operátort. 

4. G1.5) Írjunk programot, amely kiírja az (a... "2" betűket és a 0"... 9" számjegye- 
ket, valamint a hozzájuk tartozó egész értékeket. Végezzük el ugyanezt a többi 
kiírható karakterre is. Csináljuk meg ugyanezt hexadecimális jelöléssel. 

5. 02) Mi a rendszerünkön a legnagyobb és legkisebb értéke a következő típu- 
soknak: char, short, int, long, float, double, long double és unsigned? 

6. G1) Mi a leghosszabb lokális név, amit a Ct-t programokban használhatunk 
a rendszerünkben? Mi a leghosszabb külső név, amit a C-t programokban 
használhatunk a rendszerünkben? Van-e megszorítás a nevekben használható 
karakterekre? 

7. (C2) Rajzoljunk ábrát az egész és alaptípusokról, ahol egy típus egy másik típus- 
ra mutat, ha az első minden értéke minden szabványos megvalósításban ábrá- 
zolható a másik típus értékeként. Rajzoljuk meg az ábrát kedvenc C4-- 
változatunk típusaira is. 


Mutatók, tömbök és struktúrák 


, A fenséges és a nevetséges 
gyakran annyira összefüggnek, 
hogy nehéz őket szétválasztani." 
(Tom Paine) 


Mutatók s Nulla e Tömbök s Karakterliterálok s Tömbre hivatkozó mutatók s Konstansok 
e Mutatók és konstansok s Referenciák s void? s Struktúrák s Tanácsok s Gyakorlatok 


5.1. Mutatók 


Ha Tegy típus, T" a , T-re hivatkozó mutató" típus lesz, azaz egy 7" típusú változó egy 7tí- 
pusú objektum címét tartalmazhatja. Például: 


char c — a; 
char? p- éc; // a p a c címét tárolja 
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Ábrával: 





Pp: c 





er ta 











Sajnos a tömbökre és függvényekre hivatkozó mutatók esetében bonyolultabb jelölés 
szükséges: 


int" pi; // mutató egészre 

char"? ppc; // mutató char-ra hivatkozó mutatóra 

int? apl15]; // egészre hivatkozó mutatók 15 elemű tömbje 

int Cp)(char"); — // char? baraméterű függvényre hivatkozó mutató; egészet ad vissza 
intt f(cchar?); // char: paraméterű függvény; egészre hivatkozó mutatót ad vissza 


Lásd §4.9.1-et a deklarációk formai követelményeire vonatkozóan, és az ,A" függeléket 
a teljes nyelvtannal kapcsolatban. 


A mutatón végezhető alapvető művelet a , dereferencia", azaz a mutató által mutatott objek- 
tumra való hivatkozás. E műveletet indirekciónak (közvetett használatnak, hivatkozásnak) 
is hívják. Az indirekció jele az előtagként használt egyoperandusú " : 


char c — ta; 
char" p - £c; // a p a c címét tárolja 
char c2 - "p; [/c2 -7 a! 


A p által mutatott változó c, a c-ben tárolt érték a; így c2 értéke a"lesz.A tömbelemekre hi- 
vatkozó mutatókon aritmetikai műveleteket is végezhetünk (45.3), a függvényekre hivatko- 
zó mutatók pedig végtelenül hasznosak, ezeket a §7.7 pontban tárgyaljuk. 


A mutatók célja, hogy közvetlen kapcsolatot teremtsenek annak a gépnek a címzési eljá- 
rásaival, amin a program fut. A legtöbb gép bájtokat címez meg. Azok, amelyek erre nem 
képesek, olyan hardverrel rendelkeznek, amellyel a bájtokat gépi szavakból nyerik ki. Más- 
részről kevés gép tud közvetlenül egy bitet megcímezni, következésképp a legkisebb ob- 
jektum, amely számára önállóan memóriát foglalhatunk és amelyre beépített típusú muta- 
tóval hivatkozhatunk, a char. Jegyezzük meg, hogy a bool legalább annyi helyet foglal, mint 
a char (44.69. Ahhoz, hogy a kisebb értékeket tömörebben lehessen tárolni, logikai operá- 
torokat (46.2.4) vagy struktúrákban levő bitmezőket (§C.8.19 használhatunk. 
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5.1.1. Nulla 


A nulla (0) az inttípusba tartozik. A szabványos konverzióknak (§C.6.2.3) köszönhetően a 0 
integrális (44.1.1), lebegőpontos, mutató, vagy ,tagra hivatkozó mutató" típusú konstans- 
ként is használható. A típust a környezet dönti el. A nullát általában (de nem szükségszerű- 
en) a megfelelő méretű , csupa nulla" bitminta jelöli.Nincs olyan objektum, amely számára 
a 0 címmel foglalnánk helyet. Következésképpen a 0 mutató-literálként viselkedik, azt je- 
lölve, hogy a mutató nem hivatkozik objektumra.A C-ben a nulla mutatót (nullpointer) szo- 
kás a NULL makróval jelölni. A C4- szigorúbb típusellenőrzése miatt az ilyen NULL makrók 
helyett használjuk a sima 0-t, ez kevesebb problémához vezet. Ha úgy érezzük, muszáj 
a NULI-t megadnunk, tegyük azt az alábbi módon: 


const int NULL - 0 ; 


A const minősítő megakadályozza, hogy a NULL-t véletlenül újra definiáljuk és biztosítja, 
hogy a NULL-t ott is használni lehessen, ahol állandóra van szükség. 


5.2. Tömbök 


Ha Tegy típus, a 7lsize/a , size darab Ttípusú elemből álló tömb" típus lesz. Az elemek sor- 
számozása O-tól size-1-ig terjed: 


float v[3]; // három lebegőpontos számból álló tömb: uf0/, v[1], ul2] 
char" al32]; // karakterre hivatkozó mutatók 32 elemű tömbje: a[(0J .. al31/] 


A tömb elemeinek száma, mérete vagy dimenziója, konstans kifejezés kell, hogy legyen 
(§C.5). Ha változó méretre van szükségünk, használjunk vektort (§3.7.1, §16.3): 


void f(int i) 

( 
int v1[ij; // hiba: a tömb mérete nem konstans kifejezés 
vectorcint: v2(D; // rendben 

j 


A többdimenziós tömbök úgy ábrázolódnak, mint tömbökből álló tömbök: 


int d2/10//20/; // d2 olyan tömb, amely 10 darab, 20 egészből álló tömböt tartalmaz 
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A más nyelvekben tömbök méretének meghatározására használt vessző jelölés fordítási 
hibákat eredményez, mert a , (vessző) műveletsorozatot jelző operátor (46.2.2) és nem meg- 
engedett konstans kifejezésekben (4C.5). Például próbáljuk ki ezt: 


int bad[5, 2]; // hiba: konstans kifejezésben nem lehet vessző 


A többdimenziós tömböket a §C.7 pontban tárgyaljuk. Alacsonyszintű kódon kívül a leg- 
jobb, ha kerüljük őket. 


5.2.1. Tömbök feltöltése 


A tömböknek értékekből álló listákkal adhatunk kezdőértéket: 


intv1[(]-f 1, 2, 3, 47; 
charul[]-( a, b, c, 0); 


Amikor egy tömböt úgy adunk meg, hogy a méretét nem határozzuk meg, de kezdőértéke- 
ket biztosítunk, a fordítóprogram a tömb méretét a kezdőérték-lista elemeinek megszámlá- 
lásával számítja ki. Következésképp v1] és v2 típusa rendre int/4/ és charl4/ lesz. Ha a mé- 


retet megadjuk, a kezdőérték-listában nem szerepelhet annál több elem, mert ez hibának 
számít: 


char v3/2] - f a, b, 03; // hiba: túl sok kezdőérték 
char v4[3] - f a, b, 03; // rendben 


Ha a kezdőérték túl kevés elemet ad meg, a tömb maradék elemeire O lesz feltételezve: 
int v5/8] -— ( 1, 2, 3, 4); 


Az előző kód egyenértékű a következővel: 
int v5[] - ( 1, 2, 3, 4 , 0, 0, 0, 0); 


Jegyezzük meg, hogy a kezdőérték-lista nem helyettesíthető és nem bírálható felül tömb- 
értékadással: 


void JO 
( 
vá — f c, d, 02; / hiba: tömböt nem lehet értékül adni 


j 
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Ha ilyen értékadásra van szükségünk, tömb helyett használjunk vector-t (§16.3) vagy 
valarray-t (§22.4). 


A karaktertömböket kényelmi okokból karakterliterálokkal (§45.2.2) is feltölthetjük. 


5.2.2. Karakterliterálok 


A karakterliterál egy macskakörmökkel határolt karaktersorozat: 


"Ez egy karakterlánc" 


Egy karakterliterál a látszólagosnál eggyel több karaktert tartalmaz; a N0" null karakterre 
végződik, melynek értéke 0. 


sizeof( Bohr")-- 


A karakterliterálok típusa , megfelelő számú const (állandó) karakterből álló tömb", így 
a "Bohr" típusa const char[5] lesz. 


A karakterliterálokat egy cAhar"-nak is értékül adhatjuk. Ez azért megengedett, mert 
a karakterliterál típusa a C és a Ct- korábbi változataiban char" volt, így ez szükséges ah- 
hoz, hogy millió sornyi C és C4-4 kód érvényes maradjon. Az ilyen karakterliterálokat azon- 
ban hiba ilyen mutatón keresztül módosítani. 


void fO 
t 
char? p - "Platón"; 
pbl4l - e; // hiba: értékadás konstansnak; az eredmény nem meghatározott 


J 


Az effajta hibát általában nem lehet a futási időig kideríteni, és a nyelv egyes megvalósítá- 
sai is különböznek abban, hogy mennyire szereznek érvényt ennek a szabálynak. (Lásd 
még §B.2.3-at.) Az, hogy a karakterliterálok állandók, nemcsak magától értetődő, hanem azt 


is lehetővé teszi, hogy a nyelv adott változata jelentősen optimalizálhassa a karakterliterálok 
tárolásának és hozzáférésének módját. 
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Ha olyan karakterláncot szeretnénk, amit biztosan módosíthatunk, karaktereit egy tömbbe 
kell másolnunk: 


void JO 
( 
char pl ] - "Zénón"; //p egy 6 karakterből álló tömb 


PO 7 KR; // rendben 
? 


9 2 


A karakterliterál tárolási helye nem változik (statikus), így egy függvény visszatérési értéke- 
ként biztonságosan megadható: 


const char? error. messageCGint i) 


( 
Mass 


return "tartományhiba"; 
? 


J 
A range error-t tartalmazó memóriaterület tartalma nem törlődik az error. message meg- 
hívása után. 


Az, hogy két egyforma karakterliterál egyetlen memóriaterületen tárolódik-e, az adott nyel- 
vi változattól függ (4C.1: 


const char? p - "Herakleitosz"; 
const char? g - "Herakleitosz"; 


void g0 
( 


if (p -- a) cout cz "Egyezik Mm"; // az eredmény az adott C44-változattól függ 
KATA 


j 


Jegyezzük meg, hogy a mutatókra alkalmazott —— a címeket (a mutató értékeket) hasonlít- 
ja össze, nem azokat az értékeket, melyekre a mutatók hivatkoznak. 


Üres karakterláncot a ""szomszédos macskaköröm-párral írhatunk le (típusa const charf1)). 


A nem grafikus karakterek jelölésére használt fordított perjel (4C.3.2) szintén használható 
egy karakterlánc belsejében. Ez lehetővé teszi az idézőjel (" ) és a fordított perjel , escape" 
karakter ( V karakterláncon belüli ábrázolását is. Az Mi" (új sor) karakter ezek közül messze 


a leggyakrabban használt: 


coutzá!csengő az üzenet végénVaM ; 
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Az Na! karakter az ASCII BEL (csengő), amely alert-ként is ismert, kiírása pedig valamilyen 
hangjelzést eredményez. 


A karakterláncokban , igazi" sortörés nem szerepelhet: 


"Ez nem karakterlánc 
hanem formai hiba" 


A hosszú láncok , üreshely" (whitespace) karakterekkel széttördelhetők, hogy a program- 
szöveg szebb legyen: 


char alphat[ ] - "abcdefghijklmnopgrstuvwxyz" 
"ABCDEFGHIJKLMNOPORSTUVWXYZ ; 


A fordítóprogram összefűzi a szomszédos láncokat, így az albha egyetlen karakterlánccal is 
megadható lett volna: 


"rabcdefghijklmnopgrstuuwxyzABCDEFGHIJKLMNOPORSTUVWXYZ"; 


A null karaktert elvileg a karakterláncok belsejében is használhatnánk, de a legtöbb prog- 
ram nem feltételezi, hogy utána is vannak karakterek. A "ensVvo0OoMunk" karakterláncot 
például az olyan standard könyvtárbeli függvények, mint a sircpyO és a strlenO, "Jens"-ként 
fogják kezelni (420.4.1. 


Az L előtagú karakterláncok — mint amilyen az L"angst"— , széles" karakterekből (wide char) 
állnak (§4.3, 9C3.3), típusuk const wchar. (/ J. 


5.3. Tömbökre hivatkozó mutatók 


A C44-ban a tömbök és mutatók között szoros kapcsolat áll fenn. Egy tömb nevét úgy is 
használhatjuk, mint egy mutatót, amely a tömb első elemére mutat: 


intu[]-( 1, 2, 3, 4 ;; 

intt p1 — u; // mutató a kezdőelemre (automatikus konverzió) 
int" p2 - kulol; // mutató a kezdőelemre 

intt p3 - kuláAl; // mutató az "utolsó utáni" elemre 
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Ábrával: 
1 i 7 
1 


BEEE ; 














Az biztosan működik, ha a mutatót eggyel a tömb vége utáni elemre állítjuk. Ez sok algorit- 
mus számára fontos (42.7.2, §18.3). Mivel azonban egy ilyen mutató ténylegesen már nem 
mutat egy tömb elemére, nem szabad írásra vagy olvasásra használni. Nem meghatározott, 
hogy mi történik, amikor egy tömb kezdőeleme előtt levő elem címét vesszük, ezért az 
ilyesmi kerülendő. Egyes számítógépeken a tömbök gyakran a gép címzési határain kerül- 
nek lefoglalásra, így az ,eggyel a kezdőelem előtti elem" egyszerűen értelmetlen lesz. 


A tömbnevek automatikus (implici0) átalakítása mutatóvá széleskörűen használatos a C stí- 
lusú kódokban szereplő függvényhívásoknál: 


extern "C" int strlen(const char"); " // a Sstring.h: fejállományból 


void JO 

( 
char ul ] - "Annemarie"; 
char" p— u; // charl ] automatikus átalakítása char?-gá 
strlen(p); 
strlen(v); // charf ] automatikus átalakítása char?-gá 
v-p; // hiba: a tömbnek nem adható érték 


A standard könyvtár strlenO függvényének mindkét híváskor ugyanaz az érték adódik át. Az 
a bökkenő, hogy az automatikus konverziót lehetetlen elkerülni, vagyis nincs mód olyan 
függvény bevezetésre, amelynek meghívásakor a v tömb átmásolódik. Szerencsére mutató- 
ról tömbre való átalakítás nem végezhető sem automatikusan, sem definiált módon. 


A tömbparaméter automatikus mutatóvá alakítása azt jelenti, hogy a tömb mérete elvész 
a függvény számára. A függvénynek azonban valahogy meg kell határoznia a tömb mére- 
tét, hogy értelmes műveleteket hajthasson végre rajta. A C standard könyvtárában levő más 
függvényekhez hasonlóan — amelyek karakterre hivatkozó mutatókat kapnak paraméter- 
ként — az strlenO is arra számít, hogy a null karakter jelzi a karakterlánc végét, így a strlen(p) 
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a p karaktereinek a O null karakter végződésig számolt mennyiségét jelenti, nem beleértve 
a null karakter végződést . Ez meglehetősen alacsony szintű megoldás. A standard könyv- 


tárban lévő vector (§16.3.) és string (20. fejezet) esetében nincs ilyen probléma. 


5.3.1. Tömbök bejárása 


Sok algoritmus lényege a tömbökhöz és más hasonló adattípusokhoz való hatékony és , ele- 
gáns" hozzáférés (ásd §3.8, 18. fejeze). A hozzáférés egy tömbre hivatkozó mutatóval, il- 
letve egy indexszel vagy egy elemre hivatkozó mutatóval valósítható meg. Íme egy példa 
egy karakterlánc bejárására index használatával: 


void fi(char ul )) 
f 

for Gnt i — O; ulij1-O; it4) use(uliD; 
J 


Ez egyenértékű a mutatóval történő bejárással: 
void fp(char ul )) 


( 
for (char? p — v; tp!-O; pr4) use(p); 
) 


Az előtagként használt " indirekció operátor egy mutató-hivatkozást old fel, így "b a p által 
mutatott karakter lesz, a t-t pedig úgy növeli a mutatót, hogy az a tömb következő elemé- 
re hivatkozzon. Nincs olyan eredendő ok, amiért az egyik változat gyorsabb lenne a másik- 
nál. A modern fordítóprogramoknak ugyanazt a kódot kell létrehozniuk mindkét példa 
esetében (lásd §5.918]-a0 . A programozók logikai és esztétikai alapon választhatnak a válto- 
zatok között. 


Ha a 4, -, 44 vagy -- aritmetikai műveleti jeleket mutatókra alkalmazzuk, az eredmény a mu- 
tatók által hivatkozott objektumok típusától függ. Amikor egy 7" típusú p mutatóra alkal- 
mazunk egy aritmetikai operátort, akkor p-ről feltételezzük, hogy egy Ttípusú objektumok- 
ból álló tömb elemére mutat, így 9417 a tömb következő elemét jelzi, p-1 pedig az előző 
elemre mutat. Ez arra utal, hogy pt 7 egész értéke sizeoj(7-vel nagyobb lesz, mint p egész 
értéke. Hajtsuk végre a következőt: 


finclude Ciostream: 


int main O 


int vif(10]; 
short vs[10]; 
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std::cout Sz kviflo] cz !! cz gvif1] Sz Mm; 
std::cout SZ £uvs(0] cz ! ! cz gvs[1] cz Mt 


j 


Ekkor a következőt kapjuk (a mutatók értékének alapértelmezés szerinti, hexadecimális je- 
lölését használva): 


Ox 7fjfaefo 0x7fffaerá 
0x7fffaedc 0x7fffaede 


Ez azt mutatja, hogy sizeojf(short) az adott megvalósításban 2, sizeof(int) pedig 4. 


Mutatókat csak akkor vonhatunk ki egymásból definiált módon, ha mindkét mutató ugyan- 
annak a tömbnek az elemeire mutat (bár a nyelvben nincs gyors mód annak ellenőrzésére, 
hogy valóban arra mutatnak). Amikor kivonunk egy mutatót egy másikból, az eredmény 
a két mutató között lévő tömbelemek száma (egy egész típusú érték) lesz. A mutatókhoz 
egész értéket is adhatunk és ki is vonhatunk belőle egészet, az eredmény mindkét esetben 
egy mutató érték lesz. Ha ez az érték nem ugyanannak a tömbnek egy elemére mutat, 
amelyre az eredeti mutató, vagy nem eggyel a tömb mögé, az eredményül kapott mutató 
érték felhasználása kiszámíthatatlan eredményhez vezethet: 


void JO 
( 
int v1(10]; 
int v2[10]; 
int il — £v1(5]/-kv1[3]; /il-2 
int i2 - £v1l5]-k v2/3]; // meghatározhatatlan eredmény 
intt p1 — v242; //p1 - kv2I2 
intt p2 — v2-2; // "p2 nem meghatározott 


A bonyolult mutatóaritmetika rendszerint szükségtelen, ezért legjobb elkerülni. Nincs értel- 
me mutatókat összeadni, és ez nem is megengedett. 


A tömbök nem önleírók, mert nem biztos, hogy a tömb elemeinek száma is tárolódik 
a tömbbel együtt. Ez azt jelenti, hogy ahhoz, hogy bejárjunk egy tömböt, amely nem tartal- 
maz a karakterláncokéhoz hasonló végződést, valahogy meg kell adnunk a tömb elemei- 
nek számát: 
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void fp(char ul J, unsigned int size) 
( 


for (int i-0; issize; i43) use(uli)); 


const int N — 7; 
char v2INI; 
for Gint 1-0; izN; i144) use(v2[i)); 


J 


Jegyezzük meg, hogy a legtöbb C---változat a tömbök esetében nem végez indexhatár- 
ellenőrzést. A tömb ezen fogalma eredendően alacsony szintű. Fejlettebb tömbfogalmat 
osztályok használatával valósíthatunk meg (§3.7.1. 


5.4. Konstansok 


A C44 felkínálja a const, azaz a felhasználói állandó fogalmát, hogy lehetőségünk legyen 
annak kifejezésére, hogy egy érték nem változik meg közvetlenül. Ez számos esetben hasz- 
nos lehet. Sok objektumnak a létrehozás után már nem változik meg az értéke. A szimboli- 
kus konstansok (jelképes állandók) könnyebben módosítható kódhoz vezetnek, mint 
a kódban közvetlenül elhelyezett literálok. Gyakori, hogy egy értéket mutatón keresztül 
érünk el, de az értéket nem változtatjuk meg. A legtöbb függvényparamétert csak olvassuk, 
nem írjuk. 


A const kulcsszó hozzáadható egy objektum deklarációjához, jelezve, hogy az objektumot 
állandóként határozzuk meg. Mivel egy állandónak később nem lehet értéket adni, kezde- 
ti értékadást kell végeznünk: 


const int model - 90; // a model állandó 
constintu[]-( 1, 2, 3, 4); // a ulij állandó 
const int Xx; // hiba: nincs kezdeti értékadás 


Ha valamit const-ként határozunk meg, az biztosíték arra, hogy hatókörén belül értéke nem 
fog megváltozni: 


void fJO 
í 


model - 200; // hiba 
V562-A; // hiba 
J 
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Jegyezzük meg, hogy a const kulcsszó módosítja a típust és megszorítást ad arra, hogyan 
használhatunk egy objektumot, de nem határozza meg, hogyan kell az állandó számára he- 
lyet foglalni: 


void e(const X" p) 


// itt "b nem módosítható 


j 


void hO 


Xval; — // a val módosítható 
ak vaD; 
Ma 


j 


Attól függően, hogy a fordítóprogram mennyire okos, számos módon kihasználhatja egy 
objektum állandó mivoltát. Az állandók kezdeti értéke például gyakran (de nem mindig) 
egy konstans kifejezés (4C.5), ami fordítási időben kiértékelhető. Továbbá, ha a fordító- 
program tud az állandó minden használatáról, nem kell tárhelyet sem lefoglalnia számára: 


const int c1 — 1; 
const int c2 — 2; 


const int c3 - my f039; // c3 értéke fordításkor nem ismert 
extern const int c4; // cá értéke fordításkor nem ismert 
const int p - £kc2; // c2 számára tárterületet kell foglalni 


Ekkor a fordítóprogram ismeri c1 és c2 értékét, így azokat konstans kifejezésekben felhasz- 
nálhatjuk. Mivel a c3 és cá értékek fordítási időben nem ismertek (ha csak ebben a fordítá- 
si egységben levő információkat használjuk fel, lásd §9.1), c3-nak és cá-nek tárhelyet kell 
foglalni. Mivel c2 címét használjuk, c2-nek is helyet kell foglalni. A c7 konstans példa arra 
az egyszerű és gyakori esetre, amikor az állandó értéke fordítási időben ismert és számára 
nem szükséges tárat foglalni. Az extern kulcsszó azt jelöli, hogy a c£-et máshol definiáltuk 


(49.29. 


A konstansokból álló tömböknek általában szükséges helyet foglalni, mert a fordítóprog- 
ram nem tudja eldönteni, mely tömbelemekre hivatkoznak a kifejezések. Sok gépen azon- 
ban még ebben az esetben is növelhetjük a hatékonyságot, úgy, hogy a konstansokból álló 
tömböt csak olvasható memóriába tesszük. 
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A const-okat gyakran használjuk tömbök indexhatáraként és case címkéknél is: 


const int a — 42; 
const int b — 99; 
const int max - 128; 


int umaxj]; 


void f(int i) 
( 
switch (i) ( 
case a: 


ú vaő 


case b: 


ATA 


Ilyen esetekben gyakori, hogy const helyett felsoroló konstansokat (§44.8) használunk. Azt, 
hogy a const milyen módon használható osztályok tagfüggvényeivel, a §10.2.6 és §10.2.7 
pontokban tárgyaljuk. 


A szimbolikus konstansokat rendszeresen használnunk kellene arra, hogy elkerüljük a kód- 
ban a , mágikus számokat". Ha egy numerikus állandó, például egy tömb mérete, a kódban 
ismétlődik, a programot nehéz lesz átnézni, hogy a megfelelő módosításkor az állandó min- 
den egyes előfordulását kicseréljük. A szimbolikus konstansok használata viszont lokálissá 
teszi az információt. A numerikus konstansok rendszerint valamilyen, a programmal kap- 
csolatos feltételezést jelölnek. A 4 például egy egészben lévő bájtok számát, a 128 a beme- 
net átmeneti tárba helyezéséhez (puffereléséhez) szükséges karakterek számát, a 6.24 
pedig a dán korona és az amerikai dollár közötti keresztárfolyamot jelölheti. Ha ezeket az 
értékeket numerikus állandóként hagyjuk a kódban, akkor az, aki a programot karbantart- 
ja, nagyon nehezen tudja megtalálni és megérteni azokat. Ezeket az állandókat gyakran 
nem veszik észre, és érvénytelenné válnak, amikor a programot átviszik más rendszerre 
vagy ha más változások aláássák az általuk kifejezett feltételezéseket. Ha a feltevéseket 
megjegyzésekkel megfelelően ellátott szimbolikus konstansokként valósítjuk meg, minimá- 
lisra csökkenthetjük az ilyen jellegű karbantartási problémákat. 
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5.4.1. Mutatók és konstansok 


A mutatók használatakor két objektummal kapcsolatos dologról van szó: magáról a muta- 
kor az az objektumot, és nem a mutatót határozza meg állandóként. Ahhoz, hogy állandó- 
ként egy mutatót, és ne az általa mutatott objektumot vezessük be, a "const deklarátort kell 
használnunk a sima " helyett: 


void fi(char? p) 
( 
char s[ ] — "Gorm!"; 
const char? pc — s; // mutató állandóra 
bcl3] - 8; // hiba: pc állandóra mutat 
pc -p; // rendben 
char "const cp — s; // konstans mutató 
cpl3/ -— a; // rendben 
cp - p; // hiba: cp konstans 
const char ?const cpc — s; // konstans mutató állandóra 
cpc[3] - a; // hiba: cpc állandóra mutat 
cpc - p; // hiba: cpc konstans 


A "const deklarátorjelző teszi állandóvá a mutatót. Nincs azonban const" deklarátor-operá- 
tor, így a " előtt szereplő const kulcsszót az alaptípus részének tekintjük: 


char "const cp; // konstans mutató karakterre 
char const" pc; // mutató kostans karakterre 
const char? pc2; // mutató kostans karakterre 


Általában segítséget jelent, ha az ilyen deklarációkat jobbról balra olvassuk ki. Például: , cp 
egy konstans (consD mutató, amely egy karakterre (char) mutat" és , pc2 egy mutató, amely 
egy karakter-konstansra (char cons0) mutat". 


Egy objektum, amely állandó akkor, amikor mutatón keresztül férünk hozzá, lehet, hogy 
módosítható lesz akkor, ha más módon férünk hozzá. Ez különösen hasznos a függvény- 
paraméterek esetében. Azzal, hogy egy mutató-paramétert const-ként adunk meg, a függ- 
vénynek megtiltjuk, hogy módosítsa a mutató által mutatott objektumot: 


char" strcpy(char? p, const char? 9); / ?g nem módosítható 
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Egy változó címét értékül adhatjuk egy konstansra hivatkozó mutatónak, mert ebből még 
semmi rossz nem következik. Konstans címét azonban nem lehet értékül adni egy nem 
konstans mutatónak, mert ezzel megengednénk, hogy az objektum értéke megváltozzon: 


void J40O 
( 
int a — 1; 
constintc — 2; 
const intt p1 - £c; // rendben 
const intt p2 - ga; // rendben 
intt p3 - £c; // hiba: kezdeti értékadás intt-nak const intt-gal 
£p3 — 7; // kísérlet c értékének módosítására 
) 


A const-ra hivatkozó mutatókkal kapcsolatos megszorításokat meghatározott (explicit) 
típuskonverzióval küszöbölhetjük ki (§10.2.7.1 és §15.4.2.1. 


5.5. Referenciák 


A referencia (hivatkozás) egy objektum , álneve" (alias). Az ilyen hivatkozásokat általában 
függvények és különösen túlterhelt operátorok (11. fejezet) paramétereinek és visszatérési 
értékeinek megadására használjuk. Az X£ jelölés jelentése , referencia X-re". Lássunk egy 
példát: 


void JO 
t 
inti — 1; 
intik r — í; // r és i itt ugyanarra az int-re hivatkoznak 
intx — Tr; Mi 
r- 23; /i-2 
j 


Azt biztosítandó, hogy a referencia valaminek a neve legyen (azaz tartozzon hozzá objek- 
tum), a hivatkozás célpontját már létrehozáskor meg kell határoznunk: 


inti — 1; 
intik r1 — í; // rendben: r1 kapott kezdőértéket 
intik r2; // hiba: kezdeti értékadás hiányzik 


extern intik r3; // rendben: r3 máshol kap kezdőértéket 
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A referencia kezdeti értékadása nagyban különbözik a későbbi értékadástól. A látszat elle- 
nére a referencián nem hajtódik végre egyetlen művelet sem. Például: 


void gO 
( 
int ii - O; 
intik rr — tt; 
TET; // ii növelése eggyel 
intt pp - Tr; // pp az ti-re mutat 


Ez nem helytelen, de rr4-4 nem az rr értékét növeli; a 4- egy int-re hajtódik végre (ami itt 
i) . Következésképpen a referenciák értéke már nem módosítható a kezdeti értékadás után; 
mindig arra az objektumra fognak hivatkozni, amelyre kezdetben beállítottuk azokat. Az rr 
által jelölt objektumra hivatkozó mutatót £7r-rel kaphatjuk meg. 


A referencia magától értetődő módon megvalósítható (konstans) mutatóként is, amely min- 
den egyes használatakor automatikusan feloldja a mutató-hivatkozást. Nem származhat baj 
abból, ha így gondolunk a referenciákra, mindaddig, míg el nem felejtjük, hogy nem olyan 
objektumok, amelyet mutatóként kezelhetnénk: 














sttssssa a tÉSS 


ii: 1 














Egyes fordítóprogramok olyan optimalizációt alkalmazhatnak, amely a referencia számára 
futási időben szükségtelenné teszi tárterület lefoglalását. 

A referencia kezdeti értékadása magától értetődő, ha a kezdőérték egy balérték (vagyis egy 
olyan objektum, amelynek címére hivatkozhatunk, lásd 4.9.69. Egy ,sima" 7£ kezdőértéke 
T típusú balérték kell, hogy legyen. Egy const Tk esetében ez nem szükséges (sem balér- 
téknek, sem 7 típusúnak nem kell lennie), helyette az alábbiak történnek: 
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1. Először 7-re történő automatikus típuskonverzió megy végbe, ha szükséges 
ásd 4C.6-ot), 

2. aztán a kapott érték egy 7Ttípusú ideiglenes változóba kerül, 

3. végül ez az ideiglenes változó lesz a kezdőérték. 


Vegyük a következő példát: 


doubleg dr — 1; // hiba: balértékre van szükség 
const doublek cdr — 1; // rendben 


A második a következőképpen értelmezhető: 


double temp - double( 1; // először létrehozunk egy ideiglenes változót a jobb oldali 
// értékkel 
const doublek cdr- temp;  // majd ezt használjuk a cdr kezdeti értékadására 


A referencia kezdőértékét tároló ideiglenes változó a referencia hatókörének végéig marad 
fenn. A konstansok és változók hivatkozásait azért különböztetjük meg, mert a változók 
esetében nagy hibalehetőségeket rejt magában egy ideiglenes változó bevezetése, a válto- 
zónak való értékadás ugyanis a — nemsokára megszűnő - ideiglenes tárterületnek adna ér- 
téket. A konstansok hivatkozásaival nincs ilyen probléma, ami szerencsés, mert ezek gyak- 
ran függvényparaméterként játszanak fontos szerepet (411.0). 


A referenciákat olyan függvényparaméterek megadására is használhatjuk, melyeken ke- 
resztül a függvény módosíthatja a neki átadott objektum értékét: 


void increment(intk aa) f aatt; ? 


void JO 
í 
int x - 1; 
increment(x); /x5:2 


J 


A paraméterátadás a kezdeti értékadáshoz hasonló, így az increment meghívásakor az aa 
paraméter az x másik neve lesz. Ha azt szeretnénk, hogy a program olvasható maradjon, 
legjobb, ha elkerüljük az olyan függvényeket, amelyek módosítják paramétereiket. Ehelyett 
meghatározhatjuk a függvény által visszaadandó értéket vagy mutató paramétert adhatunk 
neki: 


int next(int p) ( return p3 1; ) 


void incrGint" p) ( Cp)r-; ) 
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void gO 

( 
int x — [; 
increment(x); /x:2 
Xx - next(x0); [/x7-3 
inc(kx); /x-á4 


Az increment(x) jelölés az olvasónak semmit sem árul el arról, hogy az .x értéke módosul, 
ellentétben az x-next(x) és incr(k.x) jelölésekkel. Következésképpen a , sima" referencia- 
paramétereket csak olyan esetekben használjuk, amikor a függvény neve határozottan utal 
arra, hogy ezek módosulnak. 


A referenciákat olyan függvények megadására is használhatjuk, amelyek egy értékadás bal 
és jobb oldalán egyaránt szerepelhetnek. Ez a bonyolultabb felhasználói típusok tervezése- 
kor lehet igazán hasznos. Adjunk meg például egy egyszerű asszociatív tömböt. Először ha- 
tározzuk meg a Pair adatszerkezetet: 


struct Pair f 
string name; 
double val; 

Xz 

Az alapötlet az, hogy a string-hez tartozik egy lebegőpontos érték. Könnyű elkészíteni 

a valueO függvényt, amely egy Pair-ből álló adatszerkezetet vet össze különböző karakter- 

láncokkal. Rövidítsük le a példát és használjunk egy nagyon egyszerű (persze nem túl ha- 

tékony) megvalósítást: 


vectorSPdir: pdirs; 


doublek value(const string s) 

/ 
Vesszük Pair-ek egy halmazát, 
megkeressiik s-t, ha megtaláltuk, visszaadjuk az értékét; ha nem, új Pair-t készítünk és 
visszaadjuk az alapértelmezett 0-át. 

sZ 

t 


for (int i - O; i £ pairs.sizeO; it1) 
if (s -- pairs[i.name) return pairs[í/.val; 


Pairp -ís, 03; 
bairs.push back(p); // Pair hozzáadása a végéhez (§3.7.3) 


return pairslpairs.sizeO -1].val; 
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Ezt a függvényt úgy foghatjuk fel, mint egy lebegőpontos értékekből álló tömböt, amit ka- 
rakterláncok indexelnek. Adott karakterlánccal összevetve, a valueO a megfelelő lebegő- 
pontos objektumot (nem pedig annak értékét) találja meg, és az erre vonatkozó referenciát 
adja vissza: 


int mainO // az egyes szavak előfordulásának megszámlálása a bemeneten 


( 
string buj; 


while (cin::buf) value(buf) 44; 


for (vectorgPair5::const iterator p - pairs.beginO; p!-pairs.endO; 4--p) 
cout ££ p-2name ca ": " cz p-xval cz Mi 


A while ciklus minden esetben beolvas egy szót a cin szabványos bemenetről és a buf 
karakterláncba helyezi (§3.6.), aztán növeli a hozzá tartozó számlálót. Végül kiírja az ered- 
ményül kapott táblázatot, amelyben a bemenetről kapott karakterláncok és azok előfordu- 
lásának száma szerepel. Ha a bemenet például a következő: 


aa bb bb aa aa bb aa aa 


akkor a program eredménye az alábbi: 


aa: 5 
bb: 3 


Ezt már könnyű úgy tovább finomítani, hogy valódi asszociatív tömböt kapjunk; ehhez egy 
sablon osztályt kell használnunk a túlterhelt (411.8.) / Jindexelő operátorral. Még könnyebb 
a dolgunk, ha a standard könyvtár map (417.4.1.) típusát használjuk. 


5.6. Void-ra hivatkozó mutatók 


Bármilyen típusú objektumra hivatkozó mutatót értékül lehet adni egy void" típusú válto- 
zónak, egy void" típusú változót értékül lehet adni egy másik void" típusúnak, a void" tí- 
pusú változókat össze lehet hasonlítani, hogy egyenlőek-e vagy sem, egy void" típusú vál- 
tozót pedig meghatározott módon más típusúvá lehet alakítani. A többi művelet nem lenne 
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biztonságos, mert a fordítóprogram nem tudja, hogy valójában miféle objektumra hivatko- 
zik egy ilyen mutató, ezért a többi művelet fordítási idejű hibát eredményez. Ahhoz, hogy 
egy void" típusú változót használhassunk, át kell konvertálnunk azt adott típusú mutatóvá: 


void füint" pi) 
( 
void? pv -— pi; // rendben: int? automatikus konvertálása void"-gá 
KDU; // hiba: nem lehet void?-ra hivatkozni 
bura; // hiba: void" nem növelhető (a mutatott objektum mérete ismeretlen) 
int? pi2 - static castsinttx(pv); // explicit visszaalakítás intt-ra 
double? pd1 - pu; // hiba 
double? pd2 - pi; // hiba 
double? pd3 - static castkdoublet (pw); // nem biztonságos 


j 


Általában nem biztonságos olyan mutatót használni, amely olyan típusra konvertálódik 
(casbD, amely különbözik a mutató által előzőleg hivatkozott típustól. A gép például feltéte- 
lezheti, hogy minden double 8 bájtos memóriahatáron jön létre. Ha így van, akkor furcsa mű- 
ködés származhat abból, ha a bi egy olyan int-re mutatott, amely nem így helyezkedett el 
a memóriában. Az ilyen jellegű explicit típuskényszerítés eredendően csúnya és nem bizton- 
ságos, következésképp a használt szatic cast jelölést is szándékosan csúnyának tervezték. 


A void" elsődlegesen arra használatos, hogy mutatókat adjunk át olyan függvényeknek, 
amelyek nem feltételeznek semmit az objektumok típusáról, valamint arra, hogy függvé- 
nyek nem típusos objektumokat adjanak vissza. Ahhoz, hogy ilyen objektumokat használ- 
junk, explicit típuskonverziót kell alkalmaznunk. Azok a függvények, amelyek void" típu- 
sú mutatókat használnak, jellemzően a rendszer legalsó szintjén helyezkednek el, ahol az 
igazi hardver-erőforrásokat kezelik. Például: 


void?" my alloc(size tn); // n bájt lefoglalása saját tárterületen 


A rendszer magasabb szintjein lévő void" típusú mutatókat gyanakvással kell figyelnünk, 
mert tervezési hibát jelezhetnek. Ha a void"-ot optimalizálásra használjuk, rejtsük típus- 


biztos felület mögé (413.5, §24.4.2). 


A függvényekre hivatkozó mutatókat (§7.7.) és a tagokra hivatkozó mutatókat (415.5) nem 
adhatjuk értékül void" típusú változónak. 
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5.7. Struktúrák 


A tömbök azonos típusú elemekből állnak, a szruct-ok (adatszerkezetek, struktúrák) majd- 
nem tetszőleges típusúakból: 


struct address ( 


char" name; // "Jim Dandy" 
long int number; // 61 

char" street; // "South St" 

char" town; // "New Providence" 
char statel2]; /N 

long zip; 7974 


j; 
A fenti kód egy address (cím) nevű új típust hoz létre, amely levelek küldéséhez szükséges 
címzési adatokat tartalmaz. Vegyük észre a pontosvesszőt a definíció végén. Ez egyike azon 
kevés helyeknek a C----ban, ahol pontosvesszőt kell tenni a kapcsos zárójel után, ezért so- 
kan hajlamosak elfelejteni. 


Az address típusú változókat pontosan úgy adhatjuk meg, mint más változókat, és az egyes 
tagokra a . (pont, tagkiválasztó) operátorral hivatkozhatunk: 


void JO 

( 
address jd; 
jd.name - "Jim Dandy"; 
jd.number - 61; 

j 


A tömbök kezdeti értékadására használt jelölés a struktúra-típusú változók feltöltésére is 
használható: 


address jd - ( 

Jim Dandy", 

61, "South St", 

"New Providence", (NN. J3, 7974 
J; 


Ennél azonban rendszerint jobb megoldás konstruktorokat (410.2.3) használni. Vegyük ész- 
re, hogy a jd.state-et nem lehetett volna az "N/" karakterlánccal feltölteni. Mivel a karakter- 
láncok a NO" karakterre végződnek, az "N/" három karakterből áll, ami eggyel több, mint 
ami a jd.state-be belefér. 


136 Alapok 


A struktúrák objektumaira gyakran hivatkozunk mutatókon keresztül a -: (struktúra-muta- 
tó) operátorral: 


void print addr(address? p) 
( 


cout ££ pb-xname cz Mn! 
2£ p--xnumber cz ! ! 2£ p-ostreet cz Mn 
Z£ p-town cz Mn! 
c£ p-ostatel0] c£ p-ostate[1] cz ! ! cz p-ozip cz Mt 


Ha p egy mutató, akkor p-2m egyenértékű ("p).m-mel. 


A struktúra-típusú objektumokat értékül adhatjuk, átadhatjuk függvényparaméterként, és 
visszaadhatjuk függvények visszatérési értékeként is: 


address current; 


address set current(address next) 


address prev - current; 
current - next; 


return prev; 


J 


Más lehetséges műveletek, mint az összehasonlítás (-— és /-), nem meghatározottak, de 
a felhasználó megadhat ilyeneket (11. fejezet. 


A struktúra-típusú objektumok mérete nem feltétlenül a tagok méretének összege. Ennek 
az az oka, hogy sok gép igényli bizonyos típusú objektumok elhelyezését a felépítéstől füg- 
gő memóriahatárokra, vagy eleve hatékonyabban kezeli az így létrehozott objektumokat. 
Az egészek például gyakran gépi szóhatárokon jönnek létre. Ezt úgy mondjuk, hogy az 
ilyen gépeken az objektumok jól illesztettek. Ez a struktúrákon belül , lyukakat" eredmé- 
nyez. Számos gépen a sizeof(address) például 24, nem pedig 22, ahogy az elvárható len- 
ne. Az elpazarolt helyet a lehető legkevesebbre csökkenthetjük, ha egyszerűen méret sze- 
rint rendezzük a struktúra tagjait (a legnagyobb tag lesz az első). A legjobb azonban az, ha 
olvashatóság szerint rendezzük sorba a tagokat, és csak akkor méret szerint, ha bizonyítot- 
tan szükség van optimalizálásra. 
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Egy típus neve rögtön felhasználható attól a ponttól, ahol először megjelenik, nem csak 
a teljes deklaráció után: 


struct Link ( 
Link?" previous; 
Link? successor; 


VA 


A struktúra teljes deklarációjának végéig viszont nem adhatunk meg újabb ilyen típusú ob- 
jektumokat: 


struct No good (f 
No good member; // hiba: rekurzív definíció 


J; 


Ez azért hibás, mert a fordítóprogram nem képes eldönteni a No good méretét. Két (vagy 
több) struktúra-típus kölcsönös hivatkozásához adjunk meg például egy nevet, amely a tí- 
pus neve: 


struct List; // később meghatározandó 


struct Link ( 
Link" pre; 
Link? suc; 
Link? member. of; 


Vé 


struct List f 
Link?" head; 


ő 


A List első deklarációja nélkül a Zist használata a Link deklarációjában formai hibát okozott 
volna. A struktúra-típus neve a típus meghatározása előtt is felhasználható, feltéve, hogy ez 
a használat nem igényli egy tag nevének vagy a struktúra méretének ismeretét: 


class S; — // 5" valamilyen típus neve 


extern S a; 
S JO; 

void 9(59; 
St h(S); 
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A fenti deklarációk közül azonban sok nem használható, hacsak meg nem adjuk az Stípusát: 


void k(S" p) 

( 
S a; // hiba: S nem definiált; a helyfoglaláshoz méret kell 
JO; // hiba: S nem definiált; érték visszaadásához méret kell 
(a; // hiba: S nem definiált; baraméter átadásához méret kell 
b-m - 7; // hiba: S nem definiált; a tag neve nem ismert 
St g- hp; // rendben: a mutatók számára foglalható hely és át is adhatók 
gem - 7; // hiba: $ nem definiált; a tag neve nem ismert 


A struct az osztály (10. fejeze)9) egyszerű formája. 


A C történetére visszanyúló okok miatt ugyanazzal a névvel és ugyanabban a hatókörben 
megadhatunk egy siruct-ot és egy nem struktúra jellegű típust is: 


struct stat £/5 ... "73; 
int stat(char" name, struct stat?" bup); 


Ebben az esetben a , sima" stat név a nem-struktúra neve, az adatszerkezetre pedig a struct 
előtaggal kell hivatkoznunk. Előtagként a class, union (§C.8.2) és enum (§4.8) kulcsszavak 
is használhatók, ezekkel elkerülhetjük a kétértelműséget. A legjobb azonban, ha nem ter- 
heljük túl a neveket. 


5.7.1. Egyenértékű típusok 


Két struktúra mindig különböző típusú, akkor is, ha tagjaik ugyanazok: 


struct S1 ( int a; ?); 
struct 52 ( int a; ?); 


A fenti két típus különböző, így 


51 Xx; 
S2y—-X; // hiba: nem megfelelő típus 
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A struktúra-típusok az alaptípusoktól is különböznek, ezért 


S1 Xx; 
inti- x; // hiba: nem megfelelő típus 


Minden struct-nak egyértelmű meghatározása kell, hogy legyen a programban (49.2.3.). 


5.8. Tanácsok 


[1] Kerüljük a nem magától értetődő mutató-aritmetikát. §5.3. 

[2] Ügyeljünk arra, hogy ne írjunk egy tömb indexhatárán túlra. §5.3.1. 

[3] Használjunk 0-át NUZL helyett. §5.1.1. 

[4] Használjuk a vector-t és a valarray-t a beépített (C stílusú) tömbök helyett. 
§5.3.1. 

[5] Használjunk string-et nulla végződésű karaktertömbök helyett. §5.3. 

[6] Használjunk a lehető legkevesebb egyszerű referencia-paramétert. §5.5. 

[7] Az alacsonyszintű kódot kivéve kerüljük a void?"-ot. §5.6. 

[8] Kerüljük a kódban a nem magától értetődő literálokat ( mágikus számokat"). 
Használjunk helyettük jelképes állandókat. §44.8, §5.4. 


5.9. Gyakorlatok 


1. C1 Vezessük be a következőket: karakterre hivatkozó mutató, 10 egészből álló 
tömb, 10 egészből álló tömb referenciája, karakterláncokból álló tömbre hivat- 
kozó mutató, karakterre hivatkozó mutatóra hivatkozó mutató, konstans egész, 
konstans egészre hivatkozó mutató, egészre hivatkozó konstans mutató. Mind- 
egyiknek adjunk kezdeti értéket. 

2. G1,5) Mik a char?, int", és void? mutatótípusokra vonatkozó megszorítások 
a mi rendszerünköny? Lehetne-e például egy int"-nak furcsa értéke? Segítség: 
illesztés. 
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10. 


11. 


12. 


13. 


Alapok 


. (1 Használjunk typedef-et a következők meghatározására: unsigned char, 


const unsigned char, egészre hivatkozó mutató, karakterre hivatkozó mutatóra 
hivatkozó mutató, karaktertömbökre hivatkozó mutató; 7 elemű, egészre hivat- 
kozó mutatókból álló tömb; 7 elemű, egészre hivatkozó mutatókból álló tömbre 
hivatkozó mutató; egészre hivatkozó mutatókat tartalmazó 7 elemű tömbökből 
álló 8 elemű tömb. 


. C1) Írjunk egy swap nevű függvényt, amely két egészt cserél fel. Használjunk 


int" típust a paraméterek típusaként. Írjunk egy másik swap-et is, melynek para- 
méterei intk típusúak. 


. C1,5) Mi az str tömb mérete a következő példában? 


char stl ] - "rövid karakterlánc"; 


Mi a "rövid karakterlánc" hossza? 


. (1 Készítsük el az (char), g(charg ) és h(const chark ) függvényeket. Hívjuk 


meg őket az a), 49, 3300, c, uc és sc paraméterekkel, ahol c char, uc unsigned 
char és sc signed char típusú. Mely hívások megengedettek? Mely hívásoknál 
vezet be a fordítóprogram ideiglenes változót? 


. C1,5) Készítsünk egy táblázatot, amely a hónapok neveiből és napjaik számá- 


ból áll. Írjuk ki a táblázatot. Csináljuk meg mindezt kétszer: egyszer használjunk 
karaktertömböt a nevek és egy tömböt a napok számára, másodszor használ- 
junk struktúrákból álló tömböt, ahol az egyes adatszerkezetek a hónap nevét és 
a benne levő napok számát tárolják. 


. (2) Futtassunk le néhány tesztet, hogy megnézzük, a fordítóprogram tényleg 


egyenértékű kódot hoz-e létre a mutatók használatával és az indexeléssel való 
tömbbejáráshoz (§5.3.19. Ha különböző mértékű optimalizálást lehet használni, 
nézzük meg, hat-e és hogyan hat ez a létrehozott kód minőségére. 


. C1,5) Találjunk példát, hol lenne értelme egy nevet a saját kezdőértékében 


használni. 

C1 Adjunk meg egy karakterláncokból álló tömböt, ahol a karakterláncok 

a hónapok neveit tartalmazzák. írjuk ki ezeket. Adjuk át a tömböt egy függ- 
vénynek, amely kiírja a karakterláncokat. 

(2) Olvassuk be a bemenetről szavak egy sorozatát. A bemenetet lezáró szó- 
ként használjuk a Ouit-et. Írjuk ki a beolvasott szavakat. Ne írjuk ki kétszer 
ugyanazt a szót. Módosítsuk a programot, hogy rendezze a szavakat, mielőtt 
kiírná azokat. 

(2) Írjunk olyan függvényt, amely megszámolja egy betűpár előfordulásait egy 
karakterláncban, és egy másikat, ami ugyanezt csinálja egy nulla végű karakter- 
tömbben (vagyis egy C stílusú karakterláncban). Az "ab" pár például kétszer 
szerepel az "xabaacbaxabb"-ben. 

(t1,5) Adjunk meg egy Date struktúrát dátumok ábrázolásához. Írjunk olyan 
függvényt, ami Date-eket olvas be a bemenetről, olyat, ami Date-eket 


ír a kimenetre, és olyat, ami egy dátummal ad kezdőértéket a Date-nek. 
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, Az idő előtti optimalizálás 
minden rossz gyökere." 
(D. Knuth) 


, Másrészről, nem hagyhatjuk 
figyelmen kívül 

a hatékonyságot." 

(John Bentley) 


, Asztali számológép" példa 9 Bemenet e Parancssori paraméterek e Kifejezések (áttekin- 
tés) s Logikai és összehasonlító operátorok s Növelés és csökkentés e Szabad tár 9 Meg- 
határozott típuskonverziók s Utasítások (áttekintés) s Deklarációk e Elágazó utasítások e 
Deklarációk a feltételekben " Ciklusutasítások e A hírhedt goto s Megjegyzések és behú- 
zás e Tanácsok s Gyakorlatok 
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6.1. Egy asztali számológép 


A kifejezéseket és utasításokat egy asztali számológép példáján keresztül mutatjuk be. 
A számológép a négy aritmetikai alapműveletet hajtja végre lebegőpontos értékeken. A mű- 
veleti jeleket a számok között (infix operátorként) kell megadni. A felhasználó változókat is 
megadhat. A bemenet legyen a következő: 


r- 25 
area -pitrtr 


A számológép program az alábbiakat fogja kiírni (pi előre meghatározotb: 


25 
19.635 


A 2.5 a bemenet első sorának, a 19.635 a bemenet második sorának eredménye. 


A számológép négy fő részből áll: egy elemzőből (parser), egy adatbeviteli függvényből, 
egy szimbólumtáblából és egy vezérlőből. Valójában ez egy miniatűr fordítóprogram, 
amelyben az elemző végzi a szintaktikai elemzést (vagyis a nyelvi utasítások formai elem- 
zését), az adatbeviteli függvény kezeli a bemenetet és végzi a lexikai elemzést (vagyis 
a nyelvi elemek értelmezésén, a szimbólumtábla tartalmazza a nem változó adatokat és 
a vezérlő kezeli a kezdeti értékadást, a kimenetet és a hibákat. A számológépet számos szol- 
gáltatással bővíthetjük, hogy még hasznosabbá tegyük (46.6[20]), de a kód így is elég hosszú 
lesz, és a legtöbb szolgáltatás csak a kódot növelné, anélkül, hogy további betekintést nyúj- 
tana a Ct4 használatába. 


6.1.1. Az elemző 
Íme a számológép által elfogadott nyelvtan: 


program: 
END // END a bevitel vége 
expr. list END 


expr. list: 
expression PRINT // PRINT a pontosvessző 
expression PRINT expr. list 
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expression: 
expression 4 term 
expression - term 
term 


term: 
term / primary 
term ?" primary 
brimary 


brimary: 
NUMBER 
NAME 
NAME - expression 


- primary 
( expression ) 


Más szóval, a program kifejezések sorozata, amelyeket pontosvesszők választanak el egy- 
mástól. A kifejezések alapelemei a számok, nevek és a ", /, 4, - (akár egy, akár két 
operandusú) operátorok, és az - . A neveket nem kell használat előtt definiálni. 


Az általunk használt szintaktikai elemzés módszerét rendszerint rekurzív leszállásnak 
(recursive descen0) nevezik; népszerű és lényegretörő, felülről lefelé haladó eljárás. Egy 
olyan nyelvben, mint a C-t, amelyben a függvényhívások viszonylag ,kis költségűek", 
a módszer hatékony is. A nyelvtan minden szabályára adunk egy függvényt, amely más 
függvényeket hív meg. A lezáró szimbólumokat (például az END, NUMBER, - és 2 
a get tokenO lexikai elemző, a nem lezáró szimbólumokat pedig az exprO), termO és primO 
szintaktikai elemző függvények ismerik fel. Ha egy (réspkifejezés minkét operandusa is- 
mert, a kifejezés kiértékelődik — egy igazi fordítóprogram esetében ezen a ponton történ- 
hetne a kód létrehozása. Az elemző a get tokenO függvényt használja arra, hogy bemene- 
tet kapjon. Az utolsó get tokenO hívás eredménye a curr. tok globális változóban található. 
A curr. tok változó típusa Token value felsoroló típus: 


enum Token value f 


NAME, NUMBER, END, 
PLUS- 1, MINUS- --, MUL-"t, DIV-, 
PRINT- ; , ASSIGN- -,, IP-C, RP-!) 


); 


Token value curr. tok - PRINT; 
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Az, hogy minden szimbólumot (token) a karakterének megfelelő egész értékkel jelölünk, 
kényelmes és hatékony megoldás, és segítheti azokat, akik hibakeresőt (debugger) hasz- 
nálnak. Ez a módszer addig működik, amíg bemenetként olyan karaktert nem adunk meg, 
melynek értékét felsoroló konstansként már használjuk. Én pedig nem tudok olyan karak- 
terkészletről, amelyben van olyan kiírható karakter, melynek egész értéke egy számjegyű. 
Azért választottam a curr. tok kezdeti értékeként a PRINT-et, mert a curr. tok ezt az értéket 
fogja felvenni, miután a számológép kiértékelt egy kifejezést és kiírta annak értékét. Így 
alapállapotban , indítjuk el a rendszert", a lehető legkisebbre csökkentjük annak az esélyét, 
hogy hibák forduljanak elő és egyedi indítókódra sincs szükségünk. 


Minden elemző függvénynek van egy logikai (booD (§4.2) paramétere, amely jelzi, hogy 
meg kell-e hívnia a get tokenO-t a következő szimbólum beolvasásához. A függvény kiér- 
tékeli a , saját" kifejezését és visszaadja az értékét. Az exprO függvény kezeli az összeadást 
és kivonást. A függvény egyetlen ciklusból áll, amely elemeket (zerm) keres az összeadás- 
hoz vagy kivonáshoz: 


double expr(bool get) // összeadás és kivonás 


double left - term(ge0); 


for G) // "örökké" (végtelen ciklus) 
switch (curr. tok) ( 
case PLUS: 
left 47 term(true); 
break; 
case MINUS: 
left -- term(ítrue); 
break; 
default: 


return left; 


J 


Ez a függvény önmagában nem csinál túl sokat. Egy nagyobb program magasabb szintű 
függvényeihez hasonló módon más függvényeket hív meg a feladat elvégzéséhez. 


A switch utasítás azt vizsgálja meg, hogy a switch kulcsszó után zárójelben megadott feltétel 
értéke megegyezik-e a konstansok valamelyikével. A break-kel a switch utasításból léphe- 
tünk ki. A case címkéket követő konstansoknak különbözniük kell egymástól. Ha a vizsgált 
érték nem egyezik egyik case címkével sem, a default címke választódik ki. A programozó- 
nak nem kötelező megadnia a default részt. 
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Figyeljük meg, hogy a 2-3--4-hez hasonló kifejezések (2-35)-44-ként értékelődnek ki, ahogy 
azt a nyelvtanban meghatároztuk. 


A furcsa fo1€ ; ; ) jelölés megszokott módja annak, hogy végtelen ciklust írjunk; úgy mond- 
hatjuk ki, hogy , örökké" (forever). Ez a for utasítás (46.3.3) végletes formája; helyette hasz- 
nálhatjuk a while(true) szerkezetet is. A switch utasítás végrehajtása addig ismétlődik, amíg 
nem talál a --tól és - -tól különböző jelet, amikor is a default címke utáni return utasítás 
hajtódik végre. 


Az összeadás és kivonás kezelésére a 4t- és -- operátorokat használjuk. Használhatnánk 
a left-leftátermítrue) és left-left-term(true) formát is, a program jelentése nem változna. 
A left: -termítrue) és a left--term(true) azonban nemcsak rövidebbek, hanem közvetleneb- 
bül is fejezik ki a kívánt műveletet. Minden értékadó operátor önálló nyelvi egység, így a t 
- 7 nyelvtanilag hibás a - és az - közötti szóköz miatt. 


A következő kétoperandusú műveletekhez léteznek értékadó operátorok: 
4 - sú vs 90 kk I AN za 55 


Így a következő értékadó operátorok lehetségesek: 








- 1- s k /7 907 £- - Az 2e- 557 


A 99 a moduló vagy maradékképző operátor; £, I, és A a bitenkénti ÉS, VAGY, illetve kizá- 
ró VAGY operátorok; ££ és 55 pedig a balra és jobbra léptető operátorok. A műveleti jele- 
ket és jelentésüket §6.2 foglalja össze. Ha 0 egy bináris (kétoperandusú) operátor, akkor 
x0-y jelentése x-xgy, azzal a különbséggel, hogy xx csak egyszer értékelődik ki. 


A 8. és a 9. fejezet tárgyalja, hogyan építsünk fel programot modulokból. A számológép pél- 
da deklarációit — egy kivétellel — úgy rendezhetjük sorba, hogy mindent csak egyszer és 
használat előtt adunk meg. A kivétel az exbrO, ami meghívja a termO-et, ami meghívja 
a primO-et, ami pedig ismét meghívja az exbrO-et. Ezt a kört valahol meg kell szakítanunk. 
A primO meghatározása előtti deklaráció erre való. 


double expr(booD; 


A termO függvény ugyanolyan módon kezeli a szorzást és osztást, mint ahogy az exprO ke- 
zeli az összeadást és kivonást: 
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double term(bool get) // szorzás és osztás 


t 
double left - prim(geV); 


for G) 
switch (curr. tok) ( 
case MUL: 
left "- prim(true); 
break; 


case DIV: 
if (double d - prim(true)) f 
left /7 d; 
break; 


J 


return error("Nullával nem lehet osztani"); 


default: 
return left; 


J 


J 


A nullával való osztás nem meghatározott és rendszerint végzetes hibát okoz. Ezért osztás 
előtt megnézzük, hogy a nevező 0 -e, és ha igen, meghívjuk az errorO-t. Az errorO függ- 
vényt a §6.1.4-ben ismertetjük. A d változót pontosan azon a ponton vezetjük be a program- 
ba, ahol az szükséges, és rögtön kezdeti értéket is adunk neki. Egy feltételben bevezetett 
név hatóköre a feltétel által vezérelt utasítás, az eredményezett érték pedig a feltétel értéke 
(46.3.2.15. Következésképpen a le/fi/-d osztás és értékadás csak akkor megy végbe, ha d 
nem nulla. 


A primO függvény, amely az elemi szimbólumokat kezeli, nagyban hasonlít az exprO-re és 
a termŐ-re, kivéve azt, hogy mivel már lejjebb értünk a hívási hierarchiában, némi valódi 
munkát kell végezni és nincs szükség ciklusra: 


double number value; 
string string value; 


double prim(bool ge) // elemi szimbólumok kezelése 
( 
if (geD get tokenO; 


switch (curr. tok) ( 


case NUMBER: // lebegőpontos konstans 
f double v - number. value; 

get tokenO; 

return u; 
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case NAME: 
f doublek v - tablelstring valuel[; 
if (get tokenO -- ASSIGN) v - expr(true); 
return u; 
, 
case MINUS: // egyoberandusú mínusz 


return -prim(true); 


case LP: 

f double e - expr(true); 
if (curr. tok !- RP) return erro1(") szükséges"); 
get tokenO; // !)" lenyelése 
return e; 

) 

default: 
return error( "elemi szimbólum szükséges"); 

) 

) 


Amikor egy NUMBEK-t (azaz egy egész vagy lebegőpontos literált) találunk, visszaadjuk az 
értékét. A get tokenO bemeneti eljárás elhelyezi az értéket a number. value globális válto- 
zóban. Globális változó használata a kódban gyakran jelenti, hogy a program szerkezete 
nem kristálytiszta — valamiféle optimalizációt alkalmaztak rá. Itt is ez történt. Ideális esetben 
egy nyelvi egység (exikai szimbólum) két részből áll: egy értékből, amely meghatározza 
a szimbólum fajtáját (ebben a programban ez a Token value) és (ha szükséges) a token ér- 
tékéből. Itt csak egy egyszerű curr. tok változó szerepel, így a number. value globális vál- 
tozó szükséges ahhoz, hogy az utolsó beolvasott NUMBER értékét tárolja. E kétes szerepű 
globális változó kiküszöbölését is a feladatok közé tűzzük ki (46.6[21]. A number. value ér- 
tékét nem feltétlenül szükséges a vlokális változóba menteni a get tokenO meghívása előtt. 
A számológép a számításhoz minden helyes bemenetnél használatba veszi az első számot, 
mielőtt egy másikat olvasna be, hiba esetén viszont segítheti a felhasználót, ha mentjük az 
értéket és helyesen kiírjuk. Hasonlóan ahhoz, ahogy az utolsó beolvasott NUMBER-t 
a number. value tárolja, az utolsó beolvasott MAME karakterláncot a string value tartalmaz- 
Za. Mielőtt a számológép bármit kezdene egy névvel, meg kell néznie, hogy a nevet érté- 
kül kell-e adnia vagy csak egyszerűen be kell olvasnia. Mindkét esetben a szimbólumtáblá- 
hoz fordul. A szimbólumtábla egy map (§3.7.4, §17.4.D: 


mapsstring, double: table; 


Azaz, amikor a table-t egy karakterlánccal indexeljük, az eredményül kapott érték az 
a double lesz, ami a karakterlánchoz tartozik. Tegyük fel, hogy a felhasználó a következő- 
ket írja be: 


radius - 6378.388; 
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Ekkor a számológép az alábbiakat hajtja végre: 


doubleg v — tablel"radius "I; 
// ... exprO kiszámolja az átadandó értéket 
v - 6378.388; 


A v referenciát használjuk arra, hogy a radius-hoz tartozó double értékre hivatkozzunk, 
amíg az exprO a bemeneti karakterekből kiszámítja a 6378.388 értéket. 


6.1.2. A bemeneti függvény 


A bemenet beolvasása gyakran a program legrendezetlenebb része. Ez azért van így, mert 
a programnak egy emberrel kell társalognia és meg kell birkóznia annak szeszélyeivel, szo- 
kásaival és viszonylag véletlenszerű hibáival. Kellemetlen dolog (jogosan), ha megpróbál- 
juk a felhasználót rákényszeríteni, hogy úgy viselkedjen, hogy az a gép számára megfele- 
lőbb legyen. Egy alacsonyszintű beolvasó eljárás feladata az, hogy karaktereket olvasson be 
és magasabb szintű szimbólumokat hozzon létre belőlük. Ezek a szimbólumok később 
a magasabb szintű eljárások bemeneti egységei lesznek. Itt az alacsonyszintű beolvasást 
a get tokenO végzi. Nem feltétlenül mindennapi feladat alacsonyszintű bemeneti eljáráso- 


kat írni. Sok rendszer erre a célra szabványos függvényeket nyújt. 


Két lépésben építem fel a get tokenO-t. Először egy megtévesztően egyszerű változatot ké- 
szítek, amely komoly terhet ró a felhasználóra. Ezután ezt módosítom egy kevésbé elegáns, 
de jóval használhatóbb változatra. 


Az ötlet az, hogy beolvasunk egy karaktert, felhasználjuk arra, hogy eldöntsük, milyen 
szimbólumot kell létrehozni, majd visszaadjuk a beolvasott token-t ábrázoló 7oken value 
értéket. A kezdeti utasítások beolvassák az első nem , üreshely" (whitespace, azaz szóköz, 
tabulátor, új sor stb.) karaktert c/A-ba, és ellenőrzik, hogy az olvasási művelet sikerült-e: 


Token value get tokenO 


t 
char ch — 0; 
cin:-ch; 


switch (ch) f 
case O: 
return curr. tok-END; // értékadás és visszatérés 
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Alapértelmezés szerint a 5: operátor átugorja az üreshely karaktereket és c/ értékét válto- 
zatlanul hagyja, ha a bemeneti művelet nem sikerül. Következésképpen chh-—-0 a bemenet 
végét jelzi. 


Az értékadás egy operátor, az értékadás eredménye pedig annak a változónak az értéke, 
melynek értéket adunk. Ez megengedi, hogy a curr. tok változónak az END-et adjam érté- 
kül, majd a változót ugyanabban az utasításban adjam vissza. Az, hogy egy utasítást hasz- 
nálunk kettő helyett, megkönnyíti a kód későbbi módosítását. Ha az értékadást és a vissza- 
adott értéket különválasztanánk a kódban, lehet, hogy a programozó megváltoztatná az 
egyiket, de elfelejtené módosítani a másikat. 


Nézzünk meg néhány esetet külön-külön, mielőtt a teljes függvénnyel foglalkoznánk. A ki- 
fejezések ; végződését, a zárójeleket és az operátorokat úgy kezeljük, hogy egyszerűen 
visszaadjuk az értéküket: 


case ; : 
case "FI: 
case [: 
case 4: 
case 
case (: 
case )) : 
case "7: 
return curr. tok-Token value(ch); 


A számokat így kezeljük: 


case 10": case "1: case 2: case 3: case 4: 
case 5: case 16: case "7: case 8 case 9: 
case .: 

cin putback(ch); 

cin 55 number. value; 

return curr. tok-NUMBER; 


A case címkéket függőleges helyett vízszintesen egy kupacba tenni általában nem jó ötlet, 
mert ez az elrendezés nehezebben olvasható. Fárasztó lenne azonban minden számjegyet 
külön sorba írni. Mivel a 35 műveleti jel a lebegőpontos konstansokat szabályszerűen egy 
double típusú változóba olvassa, a kód magától értetődő. Először a kezdő karaktert (szám- 
jegyet vagy ponto) visszatesszük a cin-be, majd a konstanst a number. value változóba 
helyezzük. 
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A neveket hasonlóan kezeljük: 


default: // NAME, NAME -, vagy hiba 
if (isalphaCch)) f 
cin putback(ch); 
cin:ostring value; 
return curr. tok-NAME; 
j 
error( "rossz szimbólum"); 
return curr. tok-PRINT; 


A standard könyvtárban levő isalphaO függvényt (420.4.2) használjuk arra, hogy ne kelljen 
minden karaktert felsorolnunk, mint különböző case címkéket. A karakterláncok (ebben az 
esetben a string value) 22 művelete addig olvassa a láncot, amíg üreshelyet nem talál. Kö- 
vetkezésképpen a felhasználónak szóközzel kell befejeznie az adott nevet azon operátorok 
előtt, melyek a nevet operandusként használják. Ez nem ideális megoldás, ezért erre 
a problémára még visszatérünk §6.1.3-ban. 


Íme a teljes bemeneti függvény: 


Token value get tokenO 
( 

char ch — 0; 

cin:zch; 


switch (ch) f 
case O: 
return curr. tok-END; 


case [ : 
case " 
case [/: 
case 4; 
case 
case (: 
case !) : 
case "7; 
return curr. tok-Token value(ch); 


case 10: case 1: case 2: case 3: case 4: 
case "5: case 16: case "7: case 8: case 9: 
case 1: 

cin putback(ch); 

cin 55 number. value; 

return curr. tok- NUMBER; 
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default: // NAME, NAME -, vagy hiba 
if (isalphaCcch)) f 
cin putback(ch); 
cin:ostring value; 
return curr. tok-NAME; 


) 


error( "rossz szimbólum"); 
return curr. tok-PRINT; 


Egy operátor átalakítása az operátornak megfelelő szimbólumra magától értetődő, mivel az 
operátorok token value értékét az operátor egész értékeként határoztuk meg (44.8). 


6.1.3. Alacsonyszintű bemenet 


Ha a számológépet úgy használjuk, ahogy az eddigiekben leírtuk, fény derül néhány ké- 
nyelmetlen dologra. Fárasztó emlékezni arra, hogy pontosvesszőt kell tennünk egy kifeje- 
zés után, ha ki akarjuk íratni az értékét, és nagyon bosszantó tud lenni, hogy csak 
üreshellyel lehet egy nevet befejezni. Például x-7 egy azonosító, és nem x, amit az — ope- 
rátor és a 7-es szám követ. Mindkét problémát úgy oldjuk meg, hogy a get tokenO-ben a tí- 
pussal kapcsolatos alapértelmezett bemeneti műveleteket olyan kódra cseréljük, amely 
egyenként olvassa be a karaktereket. Először is, az ,új sor" karaktert azonosként kezeljük 
a kifejezés végét jelző pontosvesszővel: 


Token value get tokenO 


( 


char ch; 


do ( // üreshelyek átugrása az Mn kivételével 
if(Icin.get(ch)) return curr. tok - END; 
) while (chI-NMn ££ isspace(ch)); 


switch (ch) f 
case 5: 
case MI: 
return curr. tok-PRINT; 


A do utasítást használjuk, amely egyenértékű a while utasítással, kivéve, hogy a ciklusmag 
mindig legalább egyszer végrehajtódik. A cin.get(ch) beolvas egy karaktert a szabványos be- 
meneti adatfolyamból cA-ba. Alapértelmezés szerint a get) nem ugorja át az üreshelyeket 
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úgy, ahogy a 22 művelet teszi. Az if(/cin.get(ch)) ellenőrzés sikertelen, ha nem olvasható be 
karakter a cin-ből; ebben az esetben END-et adunk vissza, hogy befejezzük a számológép 
működését. A / (NEM) operátort azért használjuk, mert a get igazat ad vissza, ha sikeres. 


A standard könyvtár issbace0 függvénye végzi az üreshelyek (420.4.2) szabványos vizsgá- 
latát. Ha c üreshely, az issbace(c) nem nulla értéket ad vissza, más esetben nullát. A vizsgá- 
latot táblázatban való keresésként valósítjuk meg, így az isspace0 használata sokkal gyor- 
sabb, mint az egyes üreshely karakterek vizsgálata. Hasonló függvényekkel nézhetjük meg, 
hogy egy karakter számjegy Cisdigit0), betű CisalpbhaO), esetleg betű vagy szám-e 
(GisalnumO). 


Miután átugrottuk az üreshelyeket, a következő karaktert arra használjuk, hogy eldöntsük, 
miféle nyelvi egység jön. A problémát, amit az okoz, hogy a 5: addig olvassa a karakter- 
láncot, amíg üreshelyeket nem talál, úgy oldjuk meg, hogy egyszerre egy karaktert olva- 
sunk be, amíg olyan karaktert nem találunk, ami nem szám és nem betű: 


default: // NAME, NAME-, vagy hiba 
if (isalphaCch)) f 
string value - ch; 
while (cin.get(ch) kk isalnum(ch)) string value.bush back(ch); 
cin putback(ch); 
return curr. tok-NAME; 


) 
error( "rossz szimbólum"); 
return curr. tok-PRINT; 


Szerencsére mindkét javítás elvégezhető úgy, hogy a kódnak csak egyes helyi érvényessé- 
gű részeit módosítjuk. Fontos tervezési cél, hogy olyan programokat hozzunk létre, melyek 
javítását, fejlesztését helyi módosításokkal intézhetjük. 


6.1.4. Hibakezelés 


Mivel a program ennyire egyszerű, a hibakezeléssel nem kell komolyabban törődnünk. 
Az error függvény egyszerűen megszámolja a hibákat, kiír egy hibaüzenetet, és visszatér: 


int no of errors; 


double errorCconst stringéz 5) 
no of errors44; 
cerr ££ "hiba: " cz s cc Mt 
return 1; 


J/ 
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A cerr egy átmeneti tárba nem helyezett ( nem pufferelt") kimeneti adatfolyam, amely rend- 
szerint hibajelzésre használatos (421.2.1. 


Azért adunk vissza értéket, mert a hibák jellemzően valamilyen kifejezés kiértékelése köz- 
ben történnek, így vagy teljesen abba kellene hagynunk a kiértékelést, vagy olyan értéket 
kellene visszaadnunk, amely nem valószínű, hogy további hibákat okozna. Ezen egyszerű 
számológép esetében az utóbbi megoldás megfelelő. Ha a get tokenO nyomon követte vol- 
na a sorok számát, az errorÓ tájékoztathatta volna a felhasználót a hiba pontos helyéről, 
ami akkor lenne hasznos, ha a számológépet nem interaktívan használnánk (46.6.[190. 


A program futásának gyakran be kell fejeződne, miután hiba történt, mert nincs megadva, 
milyen ésszerű módon folytathatná működését. Ezt tehetjük meg az exit0 meghívásával, 
amely először rendbe rakja az adatfolyamokat és hasonló dolgokat, majd befejezi a progra- 
mot, melynek visszatérési értéke az exitŐ paramétere lesz (49.4.1.1. 


Kivételek használatával elegánsabb hibakezelő eljárások készíthetők (ásd 48.3 és 14. feje- 
Zet), de amit most csináltunk, egy 150 soros számológépnek éppen megfelel. 


6.1.5. A vezérlő 


Miután a program minden részlete a helyére került, már csak a vezérlő kódra van szükségünk 
ahhoz, hogy elindítsuk a működést. Ebben az egyszerű példában ezt a mainO végzi el: 


int mainŐ 


( 


table! pi") - 3.1415926535897932385; // előre megadott nevek beillesztése 
tablef"e!"] - 2.7182818284590452354; 


while (cin) ( 
get tokenO; 
if (curr. tok -—- END) break; 
if (curr. tok -——- PRIND) continue; 
cout c£ expr(false) cz Mm; 


) 


return no of errors; 


J 


Hagyomány szerint a mainO O-át kell, hogy visszaadjon, ha a program hiba nélkül ér vé- 
get, más esetben nem nullát (43.29. A hibák számának visszaadásával ezt szépen megold- 
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juk. Ebben az esetben az egyetlen szükséges előkészítés az, hogy a szimbólumtáblába be- 
le kell tennünk az előre megadott neveket. A fő ciklus feladata, hogy beolvassa a kifejezé- 
seket és kiírja a választ. Ezt a következő sor oldja meg: 


cout c£ expr(false) cz Mi; 


A false paraméter mondja meg az exprO-nek, hogy nem kell meghívnia a get tokenO-t ah- 
hoz, hogy egy újabb szimbólumot kapjon, amellyel dolgozhat. 


A cin ciklusonként egyszeri ellenőrzése biztosítja, hogy a program befejeződik, ha hiba tör- 
ténik a bemeneti adatfolyammal, az END vizsgálata pedig arról gondoskodik, hogy a ciklus- 
ból megfelelően lépjünk ki, ha a get tokenO a fájl végéhez ér. A break utasítás a legköze- 
lebbi körülvevő swizcAh utasításból vagy ciklusból (azaz for, while vagy do utasításból) lép 
ki. A PRINT (azaz Més ;) vizsgálata megkönnyíti az exprO dolgát az üres kifejezések ke- 
zelésében. A continue utasítás egyenértékű azzal, hogy a ciklus legvégére ugrunk, így eb- 
ben az esetben 


while (cin) f 
Ja 
if (curr. tok -——- PRINT) continue; 
cout ££ expr(false) cz Mi; 


j 


megegyezik a következővel: 


while (cin) f 
Mese 
if (curr. tok !7- PRIND 
cout ££ expr(false) cz Mi; 


6.1.6. Fejállományok 


A számológép a standard könyvtár eszközeit használja. Ezért a megfelelő fejállományokat 
(header) be kell építenünk (include), hogy befejezzük a programot: 


includeziostream: // bemenet/kimenet 
$includesstring: // karakterláncok 
$includezmap: // asszociatív tömb 


sincludezcctypez // isalbhaO, stb. 
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Ezen fejállományok mindegyike az std névtérben nyújt szolgáltatásokat, így ahhoz, hogy az 
általuk nyújtott neveket felhasználhassuk, vagy az szd:: minősítőt kell használnunk, vagy 
a globális névtérbe kell helyeznünk a neveket a következőképpen: 


using namespace std; 


Én az utóbbit választottam, hogy ne keverjem össze a kifejezések tárgyalását a modularitás 
kérdéskörével. A 8. és a 9. fejezet tárgyalja, milyen módon lehet ezt a számológépet a név- 
terek használatával modulokba szervezni és hogyan lehet forrásfájlokra bontani. A szabvá- 
nyos fejállományoknak számos rendszeren ./ kiterjesztésű fájl megfelelőjük van, melyek le- 
írják az osztályokat, függvényeket stb. és a globális névtérbe is behelyezik azokat (49.2.1, 


§9.2.4, SB.3.1. 


6.1.7. Parancssori paraméterek 


Miután a programot megírtam és kipróbáltam, kényelmetlennek találtam, hogy először el 
kell indítani a programot, aztán be kell gépelni a kifejezéseket, végül ki kell lépni. A leg- 
gyakrabban egyetlen kifejezés kiértékelésére használtam a programot. Ha egy kifejezést 
meg lehetne adni parancssori paraméterként, jónéhány billentyűleütést megtakaríthatnánk. 


A program a mainO (§3.2., 99.4.) meghívásával kezdődik, amely két paramétert kap: az 
egyik, melyet általában argc-nek neveznek, a paraméterek (argumentumok) számát adja 
meg, a másik a paraméterekből álló tömb, ezt rendszerint argv-nek hívják. A paraméterek 
karakterláncok, ezért argy típusa char"fargc-3 1/ lesz. A program neve (ahogy az a parancs- 
sorban előfordul) argc/O/-ként adódik át, így argc értéke mindig legalább 1. A paraméterek 
listáját a null karakter zárja le, így argulargc/--0. Vegyük az alábbi parancsot: 


dc 150/1.1934 


Ekkor a paraméterek értéke a következő: 





argc: 2 


he 


"dc" "150/1.1934" 














argyu: I 
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Mivel a mainŐ meghívására vonatkozó szabályok a C nyelv követelményeivel azonosak, 
a híváskor C típusú tömbök és karakterláncok használatosak. 


A parancssori paraméterek beolvasása egyszerű, a probléma csak az, hogyan használjuk 
azokat úgy, hogy minél kevesebbet kelljen programoznunk. Az ötlet a következő: olvas- 
sunk ugyanúgy a parancssori karakterláncból, mint a bemeneti adatfolyamokból. A karak- 
terláncból olvasó adatfolyam neve — micsoda meglepetés — istringstream. Sajnos nincs 
elegáns módja annak, hogy cin-ként az istringstream-re hivatkozhassunk, ezért ki kell ta- 
lálnunk, hogy a számológép bemeneti függvényei hogyan hivatkozzanak vagy az 
istringstream-re vagy a cin-re, attól függően, milyen parancssori paramétereket adunk meg. 
Egyszerű megoldás, ha bevezetünk egy input nevű globális mutatót, amely a használandó 
bemeneti adatfolyamra mutat; minden bemeneti eljárásban ezt fogjuk felhasználni: 


istream? input; // mutató bemeneti adatfolyamra 


int main(int argc, char? argul )) 


( 

switch (argc) f 

case I: // olvasás a szabványos bemenetről 
inbut — £cin; 
break; 

case 2: // a karakterlánc paraméter beolvasása 
inbut - new istringstream(argul1)); 
break; 

default: 
error( tűl sok baraméter"); 
return 1; 

j 

tablel pi") - 3.14159265358979323595; // előre megadott nevek beillesztése 


tablel"e"] - 2.7182818284590452354; 


while Cinpun f 
get tokenO; 
if (curr. tok -—- END) break; 
if (curr. tok -——- PRINT) continue; 
cout ££ expr(false) cz Mi; 


J 


if (input !- kcin) delete input; 
return no of errors; 
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Az istringstream olyan istream, amely karakterlánc paraméteréből olvas (421.5.3). Amikor 
eléri a lánc végét, pontosan ugyanúgy jelzi azt, mint a többi adatfolyam a bemenet végét 
(§3.6, 421.3.3). Az istringstream használatához be kell építeni az csstream: fejállományt. 


Könnyű lenne úgy módosítani a mainO-t, hogy több parancssori paramétert is elfogadjon, 
de erre nincs szükség, mert egyetlen paraméterként több kifejezést is átadhatunk: 


dc "rate-1.1934;150/rate; 19. 75/rate, 21 7/rate" 
Azért használok idézőjeleket, mert a ; a UNIX rendszerekben parancs-elválasztóként hasz- 
nálatos. Más rendszerek szabályai a program indításakor paraméterek megadására vonatko- 


zóan eltérőek. 


Nem volt elegáns dolog úgy módosítani a bemeneti eljárásokat, hogy cin helyett "input-ot 
használjanak, hogy ezzel rugalmasabbak legyenek és különböző bemeneti forrásokkal mű- 
ködhessenek. A változtatás elkerülhető lett volna, ha kellő előrelátással már a kezdetektől 
bevezetünk valamilyen, az input-hoz hasonló dolgot. Általánosabb és hasznosabb megol- 
dást készíthetünk, ha észrevesszük, hogy a bemenet forrása valójában a számológép modul 
paramétere kell, hogy legyen. Az alapvető probléma, amit ezzel a számológéppel érzékel- 
tetni akartam, az, hogy a ,számológép" csak függvények és adatok gyűjteménye. Nincs 
olyan modul (42.4) vagy objektum (§2.5.29, amely kifejezett és egyértelmű módon ábrázol- 
ja a számológépet. Ha egy számológép modul vagy számológép típus tervezése lett volna 
a célom, akkor természetesen meggondoltam volna, milyen paraméterei lehetnek a modul- 
nak/típusnak (48.5[3], 410.6[16D. 


6.1.3. Megjegyzés a stílussal kapcsolatban 


A standard könyvtárbeli map szimbólumtáblaként való használata majdnem , csalásnak" 
tűnhet azoknak a programozóknak a szemében, akik nem ismerik az asszociatív tömböket. 
De nem az. A standard könyvtár és más könyvtárak arra valók, hogy használják azokat. 
A könyvtárak tervezéskor és megvalósításkor általában nagyobb figyelmet kapnak, mint 
amennyit egy programozó megengedhet magának, amikor saját kezűleg olyan kódot ír, 
amit csak egyetlen program használ fel. 


Ha megnézzük a számológép kódját (különösen az első változatot), láthatjuk, hogy nem 
sok hagyományos C stílusú, alacsonyszintű kód található benne. Számos hagyományos 
trükköt helyettesítettünk azzal, hogy olyan standard könyvtárbeli osztályokat használtunk, 
mint az ostream, string, és map (§3.4, §3.5, §3.7.4, 17.fejezeD. 
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Vegyük észre, hogy az aritmetika, a ciklusok, sőt az értékadások is viszonylag ritkán fordul- 
nak elő. Általában ilyennek kellene lennie egy olyan kódnak, amely nem kezeli a hardvert 
közvetlenül és nem él alacsonyszintű elvont adatábrázolásokkal. 


6.2. Operátorok - áttekintés 


Ez a rész összefoglalja a kifejezéseket és bemutat néhány példát. Minden operátort egy vagy 
több név követ, amely példaként szolgál az általánosan használt megnevezésekre és a szo- 
kásos használatra. A táblázatokban az osztálynév egy osztály neve, a tag egy tag neve, az 
objektum egy olyan kifejezés, amelynek az eredménye osztályobjektum, a mutató egy mu- 
tató eredményű kifejezés, a kif egy kifejezés, és a balérték egy olyan kifejezés, amely nem 
konstans objektumot jelöl. 


A típus csak akkor lehet egy teljesen általános típusnév (-gal, 0-lel stb.), ha zárójelek kö- 
zé van zárva; máshol megszorítások vonatkoznak rá (4A.5). 


A kifejezések formája független az operandusok típusától. Az itt bemutatott jelentések arra 
az esetre vonatkoznak, amikor az operandusok beépített típusúak (§4.1.19. A felhasználói 
típusú operandusokra alkalmazott operátorok jelentését magunk határozhatjuk meg (42.5.2, 
11. fejeze0. 


A táblázat minden cellájában azonos erősségű (precedenciájú) operátorok találhatók. A fel- 
sőbb cellákban levő operátorok az alsó cellákban levőkkel szemben előnyt élveznek. Pél- 
dául a4b?c jelentése at(b?c), nem pedig (a14b)?c, mert a " magasabb precedenciájú, mint 
a 1. 


Az egyoperandusú (unáris) és az értékadó operátorok jobbról balra, az összes többi balról 
jobbra értelmezendő. Például a-b-c jelentése a-(b-c), a-1bi-c jelentése (arb)-tc, "pt je- 
lentése pedig (bt), nem (DJ-t. 


Néhány nyelvtani szabályt nem lehet kifejezni a precedenciával és az asszociativitással 
(kötésseD. Például a-bac?d-e:f-g jelentése a-((DbC:(d-eJ:(f-g)), de ahhoz, hogy ezt el- 
dönthessük, meg kell néznünk a nyelvtant (4A.59. 
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Operátor — áttekintés 








hatókör-feloldás 
hatókör-feloldás 
globális hatókör 
globális hatókör 


osztálynév :: tag 
névtér név :: tag 
:: név 

:: minősített név 








tagkiválasztás 
tagkiválasztás 
indexelés 
függvényhívás 
érték létrehozása 
növelés utótaggal 
csökkentés utótaggal 
típusazonosítás 
futási idejű típusazonosítás 
futási időben ellenőrzött 
típuskényszerítés 
fordítási időben ellenőrzött 
típuskényszerítés 
nem ellenőrzött típuskényszerítés 
konstans típuskényszerítés 
objektum mérete 
típus mérete 
növelés előtaggal 
csökkentés előtaggal 
komplemensképzés 
Cdogika) nem 
mínusz előjel 
plusz előjel 
cím operátor 
indirekció 
létrehozás (memóriafoglalás) 
létrehozás (memóriafoglalás 
és kezdeti értékadás) 
létrehozás (elhelyezés) 
létrehozás (elhelyezés 
és kezdeti értékadás) 
felszámolás (felszabadítás) 
tömb felszámolása 
típuskonverzió 


objektum . tag 
mutató -: tag 
mutató [kij] 

kif (kif. lista) 
típus (kif lista) 
balérték 4-4 
balérték -— 
typeid (típus) 
typeid (kip 


dynamic cast dtípusz (kip 


static cast dtípusz (kip 


reinterpret cast dtípusz (kip 


const cast dtípusz (kip 
sizeof kif 

sizeof (típus) 

44 balérték 

-- balérték 

- kif 

! kif 

- kif 

4 kif 

k balérték 


new típus 


new (kif lista) 
new (kif lista) típus 


new (kif lista) típus (kif lista) 
delete mutató 

delete / / mutató 

(típus) kif 
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Operátor — áttekintés (folytatás) 

tagkiválasztás objektum ."tagra hivatkozó mutató 
tagkiválasztás mutató -2 "tagra hivatkozó mutató 
szorzás kif? kif 
osztás kif / kif 
moduló (maradékképzés) kif 99 kif 
összeadás (plusz) kif 3 kif 
kivonás (mínusz) kif - kif 
balra léptetés kif cz kif 
jobbra léptetés kif 22 kif 
kisebb kif c kif 
kisebb vagy egyenlő kif 7 kif 
nagyobb kif - kif 
nagyobb vagy egyenlő kif 27 kif 
egyenlő kif -- kif 
nem egyenlő kif "- kif 
bitenkénti ÉS kifg kif 
bitenkénti kizáró VAGY kif " kif 
bitenkénti megengedő VAGY kif I kif 
logikai ÉS kifík kif 
logikai megengedő VAGY kif II kif 








feltételes kifejezés kif ? kif : kif 
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Operátor — áttekintés (folytatás) 








egyszerű értékadás 

szorzás és értékadás 

osztás és értékadás 
maradékképzés és értékadás 
összeadás és értékadás 

kivonás és értékadás 

balra léptetés és értékadás 
jobbra léptetés és értékadás 

ÉS és értékadás 

megengedő VAGY és értékadás 


balérték - kif 
balérték "7 kif 
balérték /- kif 
balérték 907 kif 
balérték 47 kif 
balérték -- kif 
balérték cc- kif 
balérték 227 kif 
balérték k- kif 
balérték 1-7 kif 
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kizáró VAGY és értékadás balérték N- kif 





kivétel kiváltása throw kif 





kif , kif 


vessző (műveletsor) 











6.2.1. Eredmények 


Az aritmetikai műveletek eredményének típusát az a szabályhalmaz dönti el, amelyet , álta- 
lános aritmetikai átalakítások"-nak nevezünk (4C.6.3). A fő cél az, hogy a , legtágabb" 
operandustípussal megegyező eredmény jöjjön létre. Ha egy bináris operátor operandusa 
például lebegőpontos, a számítást lebegőpontos aritmetikával végezzük és az eredmény egy 
lebegőpontos érték lesz. Ha long típusú operandusa van, a számítás hosszú egész (/ong) arit- 
metikával történik, az eredmény pedig long érték lesz. Az int-nél kisebb operandusok (mint 
a boolés a char) intté alakulnak, mielőtt az operátort alkalmazzuk rájuk. 


Az --, cz stb. relációs (összehasonlító) operátorok logikai értékeket adnak vissza. A fel- 
használó által megadott operátorok jelentését és eredményét deklarációjuk határozza meg 


(§11.2. 


Ha egy operátornak balérték operandusa van, akkor — ha ez logikailag lehetséges — az ope- 
rátor eredménye egy olyan balérték lesz, amely a balérték operandust jelöli: 
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void f(int x, int y) 


( 
intj-x—-y; // xzy értéke az x értékadás utáni értéke 
intt p - £44X; // b x-re mutat 
intt g - R(Xt1); // hiba: xt3 nem balérték 
intt pp - í(x2yzx:y); // a nagyobb értékű int címe 


Ha a ? : második és harmadik operandusa is balérték és ugyanolyan típusúak, az eredmény 
a megfelelő típusú balérték lesz. Az, hogy ilyen módon megőrizzük a balértékeket, nagy ru- 
galmasságot ad az operátorok használatában. Ez különösen akkor fontos, ha olyan kódot 
írunk, amelynek egyformán és hatékonyan kell működnie beépített és felhasználói típusok 
esetében is (például ha olyan sablonokat vagy programokat írunk, amelyek C-- kódot hoz- 
nak létre). 


A sizeof eredménye a size t nevű előjel nélküli integrális típus, melynek meghatározása 
a ccstddef? fejállományban szerepel, a mutató-kivonásé pedig egy előjeles integrális típus, 
amit ptrdijff" t-aek hívnak és szintén a ccstiddef- fejállomány írja le. 


A fordítónak nem kell ellenőriznie az aritmetikai túlcsordulást és általában nem is teszi meg. 
Például: 


void JO 
( 
inti — 1; 
while (0 £ í) í4-; 
cout c "Az i negatív lett!" cz i cz Ni; 
j 
A ciklus előbb-utóbb az i értékét a legnagyobb egész értéken túl növeli. Ami ekkor törté- 
nik, nem meghatározott; az érték jellemzően egy negatív számig , ér körbe" (az én gépemen 
ez -2147483649). Hasonlóan, a nullával osztás eredménye sem meghatározott, ez viszont 
rendszerint a program hirtelen befejeződését eredményezi. Az alulcsordulás, a túlcsordulás 
és a nullával való osztás nem vált ki szabványos kivételeket (§14.10). 
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6.2.2. Kiértékelési sorrend 


A kifejezéseken belüli részkifejezések kiértékelési sorrendje nem meghatározott, így nem 
tételezhetjük fel például azt sem, hogy a kifejezés kiértékelése balról jobbra történik: 


int x - (21803),  / nem meghatározott, hogy fO vagy gO hívódik meg először 


Jobb kódot készíthetünk, ha a kifejezések kiértékelési sorrendje nem kötött, de a kiértéke- 
lési sorrendre vonatkozó megszorítások hiánya előre nem meghatározott eredményekhez 
vezethet: 


inti — 1; 
uli] - it4; // nem meghatározott eredmény 


A fenti kifejezés vagy v/1/-1-ként, vagy v/2/-1-ként értékelődik ki, esetleg még furcsábban 
viselkedik. A fordítóprogramok figyelmeztethetnek az ilyen kétértelműségekre, sajnos, 
a legtöbb ezt nem teszi meg. 


A , (vessző), a dd Cogikai ÉS), és a I I (logikai VAGY) operátorok esetében biztosított, 
hogy a bal oldali operandus a jobb oldali előtt értékelődik ki. A b-(a-2, a 1) például a b- 
nek 3-at ad értékül. A I I és a ££ használatára vonatkozó példák a §6.2.3-ban találhatók. 
Beépített típusoknál a £k második operandusa csak akkor értékelődik ki, ha az első 
operandus true, a I I második operandusa pedig csak akkor, ha az első operandus értéke 
Jalse;, ezt néha rövid vagy , rövidzáras" kiértékelésnek (short-circuit evaluation) nevezik. Je- 
gyezzük meg, hogy a , (vessző) műveletsor-jelző logikailag különbözik attól a vesszőtől, 
amit arra használunk, hogy a függvényhívásoknál elválasszuk a paramétereket. Nézzük az 
alábbi példát: 


JIGli] 133); // két paraméter 
J2C (alil it) J; // egy paraméter 


Az f1 meghívásának két paramétere van, 2/í/ és it, a paraméter-kifejezések kiértékelési 
sorrendje pedig nem meghatározott. Az olyan megoldás, amely függ a paraméter-kifejezé- 


sek sorrendjétől, nagyon rossz stílusról árulkodik és eredménye nem meghatározott. Az /2 


meghívásához egy paramétert adtunk meg; a (1/ij, it) ,vesszős" kifejezés, amely í-t--szal 
egyenértékű. 
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A csoportosítás kikényszerítésére zárójeleket használhatunk. Például a?b/c jelentése (atb)c, 
ezért zárójeleket kell használnunk, ha a"(b/cJ-t akarunk kapni. Az a"(b/c) kifejezés csak ak- 
kor értékelődhet ki (a?b)c-ként, ha a felhasználó nem tud különbséget tenni köztük. Az 
a" (bc) és az (a"b)/c számos lebegőpontos számításnál jelentősen különbözik, így a fordító- 
program pontosan úgy fogja az ilyen kifejezéseket kiértékelni, ahogy azokat leírtuk. 


6.2.3. Az operátorok sorrendje 


A precedencia és a , kötési" (asszociativitási) szabályok a leggyakoribb használatot tükrözik. 
Például 


if GS-0o II maxci) / ... 


azt jelenti, hogy , ha i kisebb vagy egyenlő 0-nál VAGY max kisebb i-nél". Ez egyenértékű 
az alábbival: 


if C GS-0) 11 (maxc?) ) / ... 


Az alábbi - értelmetlen, de szabályos — kifejezéssel viszont nem: 


if c—-(Ollmax) 0 / ... 


Zárójeleket használni azonban mindig hasznos, ha a programozónak kétségei vannak ezek- 
kel a szabályokkal kapcsolatban. A zárójelek használata még gyakoribb, ha a részkifejezé- 
sek bonyolultabbak. A bonyolult részkifejezések mindig hiba forrásai lehetnek, ezért — ha 
úgy érezzük, hogy szükségünk van zárójelekre — fontoljuk meg, hogy nem kellene-e egy 
külön változó használatával szétbontanunk a kifejezést. Vannak olyan esetek, amikor az 
operátorok sorrendje nem a , magától értetődő" értelmezést eredményezi: 


if (ikmask-- 0)  // hoppá! —— kifejezés k operandusaként 


Ekkor nem az történik, hogy alkalmazzuk a mask-ot az i-re, majd megnézzük, hogy az ered- 
mény 0-e. Mivel az —- előnyt élvez az £ (kétoperandusú) művelettel szemben, a kifejezés 
ig (mask--09-ként lesz értelmezve. Szerencsére a fordítóprogram könnyen figyelmeztethet 
az ilyen hibákra. Ebben az esetben a zárójelek fontosak: 


if ((ikmask) -—— 0) / ... 
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Érdemes megjegyezni, hogy a következő nem úgy működik, ahogy egy matematikus elvárná: 
if (0 Sz x - 99) / ... 


Ez megengedett, de értelmezése (0£-x)c-99, ahol az első összehasonlítás eredménye vagy 
true vagy false. A logikai értéket a fordítóprogram aztán automatikusan 1-re vagy 0-ra ala- 
kítja, amit aztán összehasonlítva 99-cel true-t kapunk. A következőképpen vizsgálhatjuk 
meg, hogy x a 0..99 tartományban van-e: 


if (0£-x £.£ xc-99) / ... 


Gyakori hiba kezdőknél, hogy a feltételekben —- (értékadást) használnak -—- (egyenlő) helyett: 


if(a - 7) / hoppá! konstans értékadás a feltételben 


Ez természetes, mert az - jelentése sok nyelvben , egyenlő". A fordítóprogramok általában 
figyelmeztetnek is erre. 


6.2.4. Bitenkénti logikai műveletek 


Az £, I, A, - 35 és c bitenkénti logikai operátorokat integrális (egész típusú) objektumok- 
ra és felsorolásokra alkalmazzuk — azaz a bool, char, short, int, long típusokra, ezek előjel 
nélküli (unsigned) megfelelőire és az enum típusokra. Az eredmény típusát a szokásos arit- 
metikai átalakítások (4C.6.3.) döntik el. 


A bitenkénti logikai operátorok jellemző felhasználása a kis halmazok (bitvektorok) fogal- 
mának megvalósítása. Ebben az esetben egy előjel nélküli egész minden bitje a halmaz egy 
elemét jelöli, és a bitek száma korlátozza a halmaz elemeinek számát. Az £ bináris operá- 
tort metszetként, a !] operátort unióként, a A-ot szimmetrikus differenciaként, a --t pedig 
komplemensként értelmezzük. Felsoroló típust arra használhatunk, hogy megnevezzük 
egy ilyen halmaz elemeit. Íme egy rövid példa, melyet az ostream megvalósításából vettünk 
kölcsön: 


enum ios base::iostate ( 
goodbit-O, eofbit-1, failbit-2, badbit-4 
J; 
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Az adatfolyam az állapotot így állíthatja be és ellenőrizheti: 


state - goodbit; 
eső 
if (stated (badbit [failbi))  / nem megfelelő adatfolyam 


A külön zárójelek azért szükségesek, mert az £ előnyt élvez a I műveleti jellel szemben. 
Egy függvény így jelezheti, hogy elérte a bemenet végét: 


state 1— eofbit; 


A 1- operátort arra használjuk, hogy az állapothoz hozzáadjunk valamilyen új információt. 
Az egyszerű state-eofbit értékadás kitörölt volna minden más bitet. 


Ezek az adatfolyam-állapotjelzők megfigyelhetők a folyam megvalósításán kívül is. Például 
így nézhetjük meg, hogyan különbözik két adatfolyam állapota: 


int diff - cin.rdstateONcout.rdstateO; // rdstateO az állapotot adja vissza 


Az adatfolyam-állapotok különbségeinek kiszámítása nem túl gyakori, más hasonló típu- 
soknál viszont alapvető művelet. Vegyük például azt az esetet, amikor össze kell hasonlíta- 
nunk azt a bitvektort, amely a kezelt megszakítások halmazát jelöli, egy másik bitvektorral, 
amely olyan megszakítások halmazát ábrázolja, melyek arra várnak, hogy kezeljék őket. 


Jegyezzük meg, hogy ezt a , zsonglőrködést" a bitekkel az iostream megvalósításából vet- 
tük és nem a felhasználói felületből. A kényelmes bitkezelés nagyon fontos lehet, de a meg- 
bízhatóság, a módosíthatóság, vagy a hordozhatóság érdekében a rendszer alacsonyabb 
szintjein kell tartanunk. Általánosabb halmazfogalomra nézzük meg a standard könyvtárbe- 
li set-et (§17.4.3), bitset-et (§17.5.3), és a vectorcbool:-t (§16.3.11). 


A mezők (4C.8.1) használata igazán kényelmes módon rövidíti le azt a műveletet, amikor 
léptetéssel és maszkolással veszünk ki bitmezőket egy szóból. Ezt természetesen megtehet- 
jük a bitenkénti logikai operátorokkal is. Egy 32 bites long középső 16 bitjét például így ve- 
hetjük ki: 


unsigned short middle(long a) f return (a228)£ Oxffjf; ? 


A bitenkénti logikai operátorokat ne keverjük össze az £g, ! I és "logikai operátorokkal. Az 
utóbbiak vagy true-t, vagy false-t adnak vissza, és elsődlegesen akkor hasznosak, amikor egy 
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if; while, vagy for utasításban (46.3.2, §6.3.3) feltételt írunk. Például az /0 (nem nulla) true 
érték, míg a -0 (a nulla komplemense) egy csupa egyesből álló bitminta, amely a -7 érték 
kettes komplemensbeli ábrázolása. 


6.2.5. Növelés és csökkentés 


A 44 operátort arra használjuk, hogy egy érték növelését közvetlenül, és nem az összeadás 
és értékadás párosításával fejezzük ki. Definíció szerint a 4-t/value jelentése Ivalue-t-17, ez 
pedig [value-lvalues 1-et jelent, feltéve, hogy a balértéknek nincs , mellékhatása". A növe- 
lendő objektumot jelölő kifejezés (csak) egyszer értékelődik ki. A csökkentést ugyanígy 
a -— operátor fejezi ki. A 4-4 és -- operátorokat használhatjuk előtagként és utótagként is. 
A 44x értéke az x új (megnövel0 értéke lesz, például az y--4-x egyenértékű az y-(xt-10- 
gyel. Az xt- értéke azonban az x régi értéke: az y-xt-4 egyenértékű az y-(t-x,xt-17,2-vel, 
ahol t egy x-szel azonos típusú változó. 


A mutatók összeadásához és kivonásához hasonlóan a mutatókra alkalmazott ---- és -- mű- 
ködését azok a tömbelemek határozzák meg, amelyekre a mutató hivatkozik; Dpt-t a b-t 
a következő tömbelemre állítja (45.3.1. 


A növelő operátorok különösen a ciklusokban használatosak, változók növelésére vagy csök- 


kentésére. Egy nulla végződésű karakterláncot például a következőképpen másolhatunk át: 


void cpy(char? p, const char" ga) 


t 
while Cprt — fgti) ; 
) 


A C-hez hasonlóan a C-r---t is szeretik és gyűlölik azért, mert megengedi az ilyen tömör, ki- 
fejezésközpontú kódolást. Mivel a 


while Cprr kezi kgti) 8; 


kifejezés meglehetősen zavaros a nem C programozók számára, ez a kódolási stílus viszont 
nem ritka a C-ben és a C4--ban, megéri közelebbről megvizsgálnunk. Vegyük először a ka- 
raktertömbök másolásának egy hagyományosabb módját: 


int length - strlen(g); 
for (int i - O, iS-length; it) plij — glil; 
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Ez pazarlás. A nulla végződésű karakterlánc hosszát úgy határozzuk meg, hogy a nulla vég- 
ződést keresve végigolvassuk azt. Így kétszer olvassuk végig a teljes láncot: egyszer azért, 
hogy meghatározzuk a hosszát, egyszer pedig azért, hogy átmásoljuk. Ezért inkább próbál- 
juk ezt: 


int í; 
for G — 0; glilr-0 ; i3) plij — glil: 
pliJ - 0; // lezáró nulla 


Az i változót indexelésre használjuk, de ki lehet küszöbölni, mert p és g mutatók: 


while Cg !- 0) f 


kp — tg; 
Dtt; // léptetés a következő karakterre 
gtt; // léptetés a következő karakterre 
? 
J 
kp - 0; // lezáró nulla 


Mivel az utótagként használt növelő operátor megengedi, hogy először felhasználjuk az ér- 
téket, és csak azután növeljük meg, a következőképpen írhatjuk újra a ciklust: 


while Cg !- 0) f 
XDt4 - gt; 


tp - 0; // lezáró nulla 


A "pr -— §g4a értéke "g, ezért a példát így módosíthatjuk: 
while (Cpt - ?gt1) /- 0) [? 


Ebben az esetben addig nem vesszük észre, hogy "g nulla, amíg be nem másoljuk ?"b-be és 
meg nem növeljük b-t. Következésképpen elhagyhatjuk az utolsó értékadást, amiben a nul- 
la végződést adjuk értékül. Végül tovább rövidíthetjük a példát azzal, hogy észrevesszük, 
nincs szükségünk az üres blokkra és hogy felesleges a ,, /-0"7 vizsgálat, mert egy mutató vagy 
integrális feltétel mindig összehasonlítódik 0-val. Így megkapjuk azt a változatot, amelyet 
célul tűztünk ki. 


while Cprt — gt) ; 


Ez a változat vajon kevésbé olvasható, mint az előző? Egy tapasztalt C vagy C44 programo- 


zó számára nem. Hatékonyabb időben és tárterületben, mint az előző? Az első változatot ki- 
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véve, ami meghívta az strlenO-t, nem igazán. Az, hogy melyik változat a leghatékonyabb, 
a gép felépítésétől és a fordítóprogramtól függ, a nulla végződésű karakterláncok másolá- 
sának leghatékonyabb módja viszont általában a standard könyvtárbeli másoló függvény. 


char" strcpy(char", const char"); // a Sstring.h2 fejállományból 


Általánosabb másolásra a szabványos copy algoritmust (§2.7.2, §18.6.1) használhatjuk. Ahol 
lehetséges, részesítsük előnyben a standard könyvtár lehetőségeit a mutatókkal és bájtok- 
kal való ügyeskedéssel szemben. A standard könyvtár függvényei lehetnek helyben kifej- 
tett függvények (47.1.1) vagy egyedi gépi utasításokkal megvalósítottak. Ezért gondosan 
fontoljuk meg, mielőtt elhinnénk, hogy valamilyen kézzel írt kódrészlet felülmúlja a könyv- 
tári függvények teljesítményét. 


6.2.6. Szabad tár 


A névvel rendelkező objektumok élettartamát (lifetime) hatókörük (44.9.4) dönti el, gyak- 
ran azonban hasznos, ha olyan objektumot hozunk létre, amely függetlenül létezik attól 
a hatókörtől, ahol létrehoztuk. Nevezetesen gyakori, hogy olyan objektumokat hozunk lét- 
re, amelyek akkor is felhasználhatók, miután visszatértünk abból a függvényből, ahol létre- 
hoztuk azokat. Az ilyen objektumokat a new operátor hozza létre és a delete operátort hasz- 
nálhatjuk felszámolásukra. A new által létrehozott objektumokra azt mondjuk, hogy ,a sza- 
bad tárban vannak?" (free store), vagy azt, hogy ,kupac-objektumok" (heap), vagyis ,a dina- 
mikus memóriában vannak". 


Nézzük meg, hogyan írnánk meg egy fordítóprogramot olyan stílusban, ahogy az asztali 
számológépnél tettük (46.19. A szintaktikai elemző függvények felépíthetnek egy kifejezés- 
fát a kódkészítő számára: 


struct Enode f 
Token value oper; 
Enode" left; 
Enode" right; 
AT 

j; 


Enode" expr(bool get) 


Enode" left - term(ge0); 
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Jor G) 

switch(curr. tok) f 

case PLUS: 

case MINUS: 

( Enode? n - new Enode; // Enode létrehozása a szabad tárban 
n-:oper - curr. tok; 
n- left - left; 
n-oright - term(true); 


left - n; 

break; 
j 
default: 

return left; // csomópont visszaadása 
j 


A kódkészítő aztán felhasználná az eredményül kapott csomópontokat (node) és törölné 
azokat: 


void generate(Enode? n) 


( 
switch (n-:oper) f 
case PLUS: 
Mass 


delete n; // Enode törlése a szabad tárból 


A new által létrehozott objektum addig létezik, amíg kifejezetten meg nem semmisítjük 
a delete-tel. Ezután a new újra felhasználhatja az objektum által lefoglalt tárhelyet. A C---r- 
változatok nem garantálják, hogy van , szemétgyűjtő" (garbage collector), amely megkeresi 
azokat az objektumokat, amelyekre nincs már hivatkozás és újra felhasználhatóvá teszi 
azok helyét. Következésképpen feltételezzük, hogy a meg által létrehozott objektumokat 
magunknak kell megsemmisítenünk, a delete-et használva. Ha van szemétgyűjtő, a delete- 


ek a legtöbb esetben elhagyhatók (4C.9.1. 


A delete operátort csak a new által visszaadott mutatóra vagy nullára lehet alkalmazni. Ha 
a delete-et nullára alkalmazzuk, nem lesz hatása. 


A new operátornak egyedi változatait is meghatározhatjuk (415.0). 
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6.2.6.1. Tömbök 


A new használatával létrehozhatunk objektumokból álló tömböt is: 


char? save string(const char? p) 


char? s - new charistrlen(p)-- 1]; 
strcpy(s,p); // másolás p-ből s-be 
return S; 


J 


int main(int argc, char?" argul 


if (argc £ 2) exit( 1; 
char? p - save string(argul1)); 
VAS 
delete[ ] p; 
j 


A ,sima" delete operátort arra használhatjuk, hogy egyes objektumokat felszámoljuk, 
a delete[ J/ tömbök felszámolására használatos. 


Ha vissza akarjuk nyerni a new által lefoglalt tárhelyet, a delete-nek vagy a deletel /-nek meg 
kell tudni állapítani, mekkora a lefoglalt objektum mérete. Ebből az következik, hogy 
a szabványos new operátorral létrehozott objektumok valamivel több helyet foglalnak, mint 
a statikus objektumok. Az objektum méretét általában egy gépi szó tárolja. 


Jegyezzük meg, hogy a vector (§3.7.1, §16.3) valódi objektum, ezért létrehozására és felszá- 
molására a sima new-t és delete-et használhatjuk: 


void (int n) 
( 
vectorsint2t p - new vectorsintx(n); // önálló objektum 
int? g - new intfn]; // tömb 
Les 
delete p; 
delete[ ] ag; 


A delete[ J operátort csak a new által visszaadott mutatóra vagy nullára alkalmazhatjuk. Ha 
a deletel /-et nullára alkalmazzuk, nem lesz hatása. 
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6.2.6.2. Memória-kimerülés 


A szabad tár new, delete, newl Jés deletel ]/ operátorai függvényekként vannak megvalósítva: 


void? operator new(size 1; // hely az önálló objektum számára 
void operator delete(void"); 


void? operator neul I(size 1); // hely a tömb számára 
void operator delete[ void"); 


Ha a new operátornak egy objektum számára kell helyet foglalnia, az oberator newO-t hív- 
ja meg, hogy az megfelelő számú bájtot foglaljon le. Ha tömb számára foglal helyet, az ope- 
rator neul JO meghívására kerül sor. Az operator new és az operator new [ JO szabványos 


megvalósítása a visszaadott memóriát nem tölti fel kezdőértékkel. 


Mi történik, ha a new nem talál lefoglalható helyet? Alapértelmezés szerint a lefoglaló 
bad alloc kivételt vált ki (a másik lehetőséget illetően lásd §19.4.5-ö0: 


void JO 
( 
try ( 


J 
catch(bad alloc) ( 


cerr c£ "Elfogyott a memória Nm"; 


JorG;) new char[100007; 


J 


J 


Akármennyi memória áll a rendelkezésünkre, a kód végül meg fogja hívni a bad alloc ese- 


ménykezelőjét. 


Magunk is meghatározhatjuk, mit csináljon a new, amikor kifogy a memória. Ha a new nem 
jár sikerrel, először azt a függvényt hívja meg, amelyet a Cnew: fejállományban bevezetett 


set new handlerŐ függvénnyel előzőleg beállítottunk (amennyiben ezt megtettük): 


void out of store0 
( 
cerr 22 "Az operator new nem járt sikerrel: nincs tárhelyn"; 


throw bad allocO; 


J 
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int mainŐ 


( 


set new handlerCout of store); // out of store lesz a new handler 
for G;) new char[10000]; 
cout cz "késztn ; 


J 


Ez azonban soha nem fog elérni addig, hogy kiírja a , kész"-t. Ehelyett a következőt fogja 
kiírni: 


Az operator new nem járt sikerrel: nincs tárhely 


Lásd §14.4.5-öt az operator newO egy olyan lehetséges megvalósításáról, amely megvizs- 
gálja, létezik-e meghívható kezelőfüggvény, és ha nem talál ilyet, bad alloc-ot vált ki. Egy 
new handler azonban valami okosabbat is tehet, mint hogy egyszerűen befejezi a progra- 
mot. Ha tudjuk, hogyan működik a new és a delete — például azért, mert saját oberator 
new -t és operator deleteO-et írtunk — a kezelőfüggvény megpróbálhat valamennyi memó- 
riát keresni, hogy a new visszatérhessen, vagyis a felhasználó gondoskodhat szemétgyűjtő- 
ről, így elhagyhatóvá teheti a delete-et (bár ez kétségtelenül nem kezdőknek való felada0. 
Majdnem mindenkinek, akinek automatikus szemétgyűjtőre van szüksége, a leghaszno- 
sabb, ha szerez egy már megírt és ellenőrzött terméket (4C.9.1). 


Azzal, hogy új new handler-t állítunk be, felvállaljuk, hogy nekünk kell törődnünk a me- 
mória kimerülésével kapcsolatos problémákkal a new minden használatakor. A memória- 
foglalásnak kétféle útja létezik: vagy gondoskodunk nem szabványos lefoglaló és felszaba- 
dító függvényekről (415.6) a new szabályos használata számára, vagy a felhasználó által 
adott további foglalási adatokra támaszkodunk (§10.4.11, §19.4.5.). 


6.2.7. Meghatározott típuskonverziók 


Néha , nyers memóriával" kell dolgoznunk, azaz a tár olyan objektumot tartalmaz vagy fog 
tartalmazni, melynek típusa ismeretlen a fordítóprogram számára. Ilyen eset, amikor a me- 
móriafoglaló (allokátor) egy újonnan lefoglalt memóriaterületre hivatkozó void" típusú mu- 
tatót ad vissza, vagy ha azt akarjuk kifejezni, hogy egy adott egész értéket úgy kell kezelni, 
mint egy [/O eszköz címét: 


void? malloc(rsize 0); 


void JO 

( 
int? p -— static castsint(malloc(100)9; // a new által lefoglalt helyet int-ként használjuk 
IO device? d1 - reinterpret cast£IO devicetr:(OXff00), // eszköz a OXffO0 címen 
sed 


J 
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A fordítóprogram nem ismeri a void" által mutatott objektum típusát. Azt sem tudja, vajon 
a OXff00 érvényes cím-e. Következésképpen az átalakítások helyessége teljes mértékben 
a programozó kezében van. Az explicit (pontosan meghatározot) típuskényszerítések 
(casting) néha szükségesek, de hagyományosan túl sokszor használják azokat, és jelentős 
hibaforrások. 


A static cast operátor egymással kapcsolatban levő típusok közötti konverziót végez, pél- 
dául két, ugyanazon osztályhierarchiában lévő mutatótípus, integrális típus és felsoroló tí- 
pus, vagy lebegőpontos típus és integrális típus közöttit. A reinterpret class olyan típusok 
átalakítását hajtja végre, amelyek nincsenek kapcsolatban, például egészről mutatóra vagy 
mutatótípusról egy másik, nem rokon mutatóra konvertál. Ez a megkülönböztetés lehetővé 
teszi, hogy a fordítóprogram elvégezzen bizonyos minimális típusellenőrzést a static cast 
esetében, és megkönnyíti, hogy a programozó megtalálja a veszélyesebb átalakításokat, 
melyeket a reinterpret cast jelöl. Néhány static cast , hordozható", a reinterbret cast-ok 
közül viszont csak kevés. A reinterpret cast esetében nem sok dolog biztos; általában új tí- 
pust hoz létre, amelynek ugyanaz a bitmintája, mint a paraméteréé. Ha a cél legalább annyi 
bites, mint az eredeti érték, az eredményt a reinterpret cast-tal az eredeti típusra alakíthat- 
juk és használhatjuk azt. A reinterpret cast eredményét csak akkor lehet biztosan felhasz- 
nálni, ha annak típusa pontosan az a típus, amelyet az érték meghatározására használtunk. 


Ha kísértést érzünk, hogy pontosan meghatározott típuskényszerítést alkalmazzunk, szán- 
junk időt arra, hogy meggondoljuk, vajon tényleg szükséges-e. A C4--ban az explicit tí- 
puskényszerítés a legtöbb esetben szükségtelen olyankor, amikor a C-ben szükség lenne rá 
(§1.69, és sok olyan esetben is, ahol a C-t korai változataiban szükséges volt (41.6.2, §B.2.3). 
Számos programban az ilyen típuskonverzió teljesen elkerülhető; máshol néhány eljárásra 
korlátozhatjuk a használatát. Ebben a könyvben explicit típuskényszerítést valósághű hely- 
zetekben csak a 46.2.7, §7.7, §13.5, §15.4, és §25.4.1 pontokban használunk. 


A futási időben ellenőrzött konverziók egyik formája a dynamic cast (§15.4.1. A const 
minősítőt eltávolító , konstanstalanító" const cast(§15.4.2.1) operátort szintén használhatjuk. 


A C44 a C-ből örökölte a (7e jelölést, amely bármilyen átalakítást elvégez, amit ki lehet fe- 
jezni a static cast, reinterpret castés a const cast kombinációjaként. Eredményül 7 típusú 
érték jön létre (§B.2.39. Ez a C stílusú konverzió sokkal veszélyesebb, mint a fent említettek, 
mert a jelölést nehezebben lehet észrevenni egy nagy programban és a programozó szán- 
déka szerinti átalakítás fajtája nem nyilvánvaló. Azaz a (e lehet, hogy , hordozható" átala- 
kítást végez egymással kapcsolatban levő típusok között, de nem hordozhatót a nem rokon 


típusok között, esetleg egy mutatótípusról eltávolítja a const minősítőt. Ha nem tudjuk Tés 
e pontos típusát, ezt nem tudjuk eldönteni. 
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6.2.8. Konstruktorok 


Egy Ttípusú érték létrehozása egy e értékből a 7(e) függvényjelöléssel fejezhető ki: 


void K(Iddouble d) 
int i - int(d); // d csonkolása 
complex z - complex(d); // complex létrehozása d-ből 
ete 

j 


A 1(e) szerkezetet néha függvény stílusú konverziónak nevezik. Sajnos, beépített 7 típu- 
sokra 1(e) egyenértékű (7e-vel, ami azt vonja maga után, hogy a 7(e) használata nem min- 
dig biztonságos. Aritmetikai típusok esetében az értékek csonkulhatnak, és még egy 
hosszabb egész típusról egy rövidebbre (például long-ról char-ra) való átalakítás is nem 
meghatározott viselkedést eredményezhet. A jelölést megpróbálom kizárólag ott használni, 
ahol az érték létrehozása pontosan meghatározott, azaz a szűkítő aritmetikai átalakítások- 
nál (4C.6), az egészekről felsoroló típusra való átalakításoknál (44.8), és a felhasználói típu- 
sok objektumainak létrehozásánál (42.5.2, §10.2.3). 


A mutató-konverziókat a 7(e) jelölést használva nem fejezhetjük ki közvetlenül. A char" (2) 
például formai hibának számít. Sajnos az a védelem, amit a konstruktor jelölés nyújt az ilyen 
veszélyes átalakítások ellen, kikerülhető ha a mutatótípusokra typedef neveket (44.9.7) 
használunk. 


A T alapértelmezett értékének kifejezésére a 710 konstruktor jelölés használatos: 


void (double d) 

t 
int j — intO; // alapértelmezett int érték 
complex z - complex; // alapértelmezett complex érték 
Me 

J 


A beépített típusok konstruktorának értéke a 0, amit a fordító az adott típusra konvertál 
(44.9.5). Ezért az int egy másfajta módja a O írásának. A Tfelhasználói típusra 70-t az alap- 
értelmezett konstruktor (410.4.2) határozza meg, ha létezik ilyen. 


A konstruktor jelölés használata beépített típusokra sablonok írásakor különösen fontos. 
Ekkor a programozó nem tudhatja, hogy a sablon (template) paramétere beépített vagy fel- 
használói típusra vonatkozik-e majd (§16.3.4, §17.4.1.2). 
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6.3. Utasítások - áttekintés 


Íme a Cr utasítások összefoglalása, néhány példával: 





Az utasítások formai szabályai 








utasítás: 
deklaráció 
€ utasítás lista em kötelező? 
try ( utasítás lista nem kötelező! kezelő lista 
kif nem kötelező ; 
if (feltétel) utasítás 
if (feltétel) utasítás else utasítás 
switch (feltéte utasítás 
while (feltétel) utasítás 
do utasítás while (kip); 
for (kezdőérték meghatározó feltétel em kötelező ; Rifnem kötelező ) Wtasítás 
case konstans kif: utasítás 
default : utasítás 
break ; 
continue ; 
return k ifnem kötelező ; 
goto azonosító; 
azonosító : utasítás 


utasítás lista: 
utasítás utasítás TiSta, em kötelező 


feltétel: 
kif 


típusazonosító deklarátor - kif 


kezelő lista: 
catch (kif deklaráció) ( utasítás liStd em kötelező? 


kezelő lista kezelő TiSta em kötelező 
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Jegyezzük meg, hogy a deklaráció egy utasítás, értékadó és eljáráshívó utasítások pedig 
nincsenek: az értékadások és a függvényhívások kifejezések. A kivételek kezelésére vonat- 
kozó utasításokat — a try blokkokat — a §8.3.1 pontban tárgyaljuk. 


6.3.1. Deklarációk mint utasítások 


A deklaráció utasítás. Hacsak egy változót szatic-ként nem adunk meg, minden esetben kez- 
dőértéket fog kapni, amikor a vezérlés áthalad a deklarációján (lásd még §10.4.8). A dekla- 
rációkat azért engedjük meg minden olyan helyen, ahol utasítást használhatunk (és még pár 
további helyen, §6.3.2.1, §6.3.3.1), hogy lehetővé tegyük a programozónak a kezdőérték 
nélküli változókból származó hibák csökkentését és a változók hatókörének lehető legna- 
gyobb szűkítését a kódban. Ritkán van ok új változó bevezetésére, mielőtt lenne egy olyan 
érték, amit a változónak tartalmaznia kell: 


void Kvectorsstring:£ v, int i, const char? p) 
( 

if (p--0) return; 

if G2O 11 v.size0S-0) errorC rossz index"); 


string s — ulij; 
if(s --p)( 
ra 
, 
Ms 
J 


A lehetőség, hogy a deklarációkat végrehajtható kód után is elhelyezhetjük, alapvető fon- 
tosságú sok konstans esetében, illetve az olyan egyszeri értékadásos programozási stílus- 
nál, ahol egy objektum értéke nem változik meg annak létrehozása és kezdeti értékadása 
után. Felhasználói típusoknál a változó meghatározásának elhalasztása addig, amíg egy 
megfelelő kezdeti érték rendelkezésre nem áll jobb teljesítményhez is vezethet: 


string s; / ...5/s - "A legjobb a jó ellensége." ; 
A fenti könnyen előfordulhat, hogy sokkal lassabb, mint a következő: 
string s - "Voltaire"; 


Kezdeti érték nélkül általában akkor adunk meg egy változót, ha a változónak utasításra van 
szüksége a kezdeti értékadáshoz. Ilyenek például a bemeneti változók és a tömbök. 
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6.3.2. Kiválasztó utasítások 
Egy értéket az ifvagy a switch utasítással vizsgálhatunk meg: 
if (feltétel utasítás 


if (feltétel) utasítás else utasítás 
switch (feltétel) utasítás 


Az alábbi összehasonlító operátorok a logikai (booD típusú true értéket adják vissza, ha az 
összehasonlítás igaz, és false-t, ha hamis: 


— — je 2 sz 5 5- 


Az ifutasításban az első (és egyetlen) utasítás akkor hajtódik végre, ha a kifejezés nem nul- 
la. Ha nulla, a második utasításra ugrunk (ha megadtunk ilye). Ebből az következik, hogy 
bármilyen aritmetikai vagy mutató kifejezést lehet feltételként használni. Például ha x egy 
egész, akkor 


if 69 / ... 
azt jelenti, hogy 


if (x 1-0) // ... 


A p mutató esetében az alábbi egy közvetlen utasítás, ami azt a vizsgálatot fejezi ki, hogy ,p 
egy érvényes objektumra mutat": 


if (DD ... 


A következő közvetett módon ugyanezt a kérdést fogalmazza, úgy, hogy összehasonlítja 
egy olyan értékkel, amelyről tudjuk, hogy nem mutat objektumra: 


if(p1-0)//... 


Jegyezzük meg, hogy a 0 mutatót nem minden gép ábrázolja , csupa nullával" (§5.1.19. Min- 
den fordítóprogram, amivel találkoztam, ugyanazt a kódot készítette mindkét vizsgálatra. 


6. Kifejezések és utasítások 179 


kk I] ! 


logikai operátorok leggyakrabban feltételekben használatosak. Az ££k és a I I műveletek 
nem értékelik ki a második paramétert, csak ha szükség van rá: 


if (pb kk 1£p-2count) / ... 


A fenti utasítás például először megvizsgálja, hogy b nem nulla-e, és csak akkor nézi meg, 
hogy I£p-2count teljesül-e, ha b nem nulla. 


Néhány if utasítást kényelmesen feltételes kifejezésekre cserélhetünk. Például az 


if (a £- b) 
max — b; 
else 
max — a; 


jobban kifejezhető így: 


max - (aS-b) ? b : a; 


A feltétel körül lévő zárójelek nem szükségesek, én azonban úgy gondolom, a kód 
könnyebben olvasható lesz tőlük. 


A switch utasítás if utasítások sorozataként is leírható. Például a 


switch (val f 
case I: 
JE 
break; 
case 2: 
20; 
break; 
default: 
hO; 
break; 
J 
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így is kifejezhető: 


if (val -- 1) 
JO; 

else if (val -——- 2) 
20; 

else 


ho; 


A jelentés ugyanaz, de az első (switch) változatot részesítjük előnyben, mert a művelet ter- 
mészete (egy értéket állandók halmazával hasonlítunk össze) így világosabb. A switch uta- 
sítás olvashatóbb olyan példáknál, amelyek nem maguktól értetődőek, és jobb kódot is 
hozhatunk létre vele. 


Vigyázzunk arra, hogy a switch case-ét mindig fejezzük be valahogy, hacsak nem akarjuk 
a végrehajtást a következő case-nél folytatni. Vegyük a következőt: 


switch (val) ( // vigyázat! 
case I: 
cout ca "1. eseNm gy 
case 2: 
cout c£ "2.eseNn Tt; 
default: 
cout 2 "Alapértelmezés: nincs ilyen eseNn"; 


j 


Ha val--1-gyel hívjuk meg, a következőket írja ki: 


1. eset 
2. eset 
Alapértelmezés: nincs ilyen eset 


Ez az avatatlanokat nagy meglepetésként érheti. Jó ötlet, ha megjegyzésekkel látjuk el azon 
(ritka) eseteket, amikor a case-ek közötti továbblépés szándékos, így egy nem magyarázott 
továbblépésről feltételezhetjük, hogy programhiba. A case befejezésének leggyakoribb 
módja a break használata, de a return is hasznos lehet (46.1.1). 
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6.3.2.1. Deklarációk feltételekben 


A véletlen hibás működés elkerülésére általában jó ötlet a változókat a legkisebb lehetséges 
hatókörben bevezetni. Nevezetesen, rendszerint legjobb elhalasztani egy ideális változó be- 
vezetését addig, amíg kezdeti értéket nem tudunk adni neki. Így nem kerülhetünk olyan 
helyzetbe, hogy a változót még azelőtt használjuk, mielőtt kezdeti értékét beállítottuk volna. 


Az említett két elv egyik legelegánsabb felhasználása, ha a változót egy feltételben adjuk 
meg. Vegyük a következő példát: 


if (double d - prim(true)) ( 
left /- d; 
break; 


Itt d deklarált és kezdőértéket is kap, amit a feltétel értékével hasonlítunk össze. A d ható- 
köre a deklaráció pontjától annak az utasításnak a végéig terjed, amit a feltétel vezérel. Ha 
volna egy else ág az ifutasításban, a d hatóköre mindkét ágra kiterjedne. 


A másik hagyományos és kézenfekvő megoldás, ha a dt-t a feltétel előtt vezetjük be. Így vi- 
szont nagyobb lesz a d használatának hatóköre; kiterjedhet a kezdeti értékadás elé vagy a d 
szándékolt hasznos élettartama után is: 


double d; 
108 
d2- d; // hoppá! 
VAN 
if (d - prim(rue)) ( 
left /- d; 
break; 
) 
0 
d — 2.0; // d két, egymástól független használata 


A változók feltételekben történő megadásának nemcsak logikai haszna van, tömörebb for- 
ráskódot is eredményez. 


A feltételben lévő deklarációnak egyetlen változót vagy konstanst kell megadnia és feltöl- 


tenie kezdőértékkel. 
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6.3.3. Ciklusutasítások 


A ciklusokat for, while vagy do utasítással fejezhetjük ki: 


while ( feltétel ) utasítás 
do utasítás while ( kifejezés ) ; 
for ( kezdőérték meghatározó feltétel em kötelező ; KIFEJEZÉS nem kötelező ) utasítás 


Ezen utasítások mindegyike ismételten végrehajt egy utasítást (amit vezérelt (controlled) 
utasításnak vagy ciklusmagnak nevezünk), amíg a feltétel hamissá nem válik vagy a prog- 
ramozó más módon ki nem lép a ciklusból. 


A for utasítás szabályos ciklusok kifejezésére való. A ciklusváltozót, a ciklusfeltételt, és 
a ciklusváltozót módosító kifejezést egyetlen sorban írhatjuk le, ami nagyon megnövelheti 
az olvashatóságot és ezzel csökkentheti a hibák gyakoriságát. Ha nem szükséges kezdeti ér- 
tékadás, a kezdőérték meghatározó (inicializáló) utasítás üres is lehet. Ha a feltételt elhagy- 
juk, a for utasítás örökké a ciklusban marad, hacsak a felhasználó kifejezetten kilépésre 
nem kényszeríti egy break, return, goto, vagy throw utasítással, vagy valami kevésbé egy- 
szerű módon, például az exit0 (§9.4.1.1) meghívásával. Ha a kifejezést elhagyjuk, a ciklus- 
magban kell módosítanunk egy ciklusváltozót. Ha a ciklus nem az egyszerű , bevezetünk 
egy ciklusváltozót, megvizsgáljuk a feltételt, módosítjuk a ciklusváltozót" fajtából való, álta- 
lában jobb, ha while utasítással fejezzük ki, de a for is segíthet olyan ciklusok írásánál, 
melyeknek nincs meghatározott leállási feltétele: 


JorGDt "örökké" (végtelen ciklus) 
Sze, 


j 


A while utasítás egyszerűen végrehajtja a ciklusmagot, amíg feltétele hamissá nem válik. Ak- 
kor hajlok arra, hogy a while-t részesítsem előnyben a /or-ral szemben, amikor nincs magá- 
tól értetődő ciklusváltozó vagy amikor a ciklusváltozó módosítása természetes módon 
a ciklusmag közepén történik. A bemeneti ciklus egy olyan ciklusra példa, amelyben nincs 
magától értetődő ciklusváltozó: 


while(cin:2ch) / ... 


Tapasztalatom szerint a do utasítás könnyen hibák és tévedések forrása lehet. Ennek az az 
oka, hogy a ciklusmag mindig végrehajtódik egyszer, mielőtt a feltétel kiértékelődik. Ahhoz 
azonban, hogy a ciklusmag megfelelően működjön, valamilyen feltételnek már az első al- 
kalommal is teljesülnie kell. A vártnál sokkal gyakrabban vettem észre azt, hogy egy felté- 
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tel nem úgy teljesült, ahogy az elvárható lett volna; vagy amikor a programot először meg- 
írták és tesztelték, vagy később, amikor a kódot módosították. Ezenkívül jobban szeretem 
a feltételt , elöl, ahol jól láthatom". Következésképpen én magam próbálom elkerülni a do 
utasításokat. 


6.3.3.1. Deklarációk a for utasításban 


Változókat a for utasítás kezdőérték-adó részében adhatunk meg. Ha ez deklaráció, akkor 
az általa bevezetett változó (vagy változók) hatóköre a for utasítás végéig terjed: 


void f(int al J, int max) 


( 
for Gint i - O; izmax; i44) ulij — ii; 


j 


Ha az index végső értékét tudni kell a for ciklusból való kilépés után, a ciklusváltozót a cik- 
luson kívül kell megadni (pl. §6.3.4.). 


6.3.4. Goto 


A C44-ban megtalálható a hírhedt goto : 


goto azonosító ; 
azonosító : utasítás 


A goto az általános magasszintű programozásban kevés dologra használható, de nagyon 
hasznos lehet, amikor a Cs kódot program és nem közvetlenül egy személy készíti; hasz- 
nálhatjuk például olyan elemzőben, melyet egy kódkészítő program (kódgenerátor) hozott 
létre valamilyen nyelvtan alapján. A goto akkor is hasznos lehet, ha a hatékonyság alapve- 
tő követelmény, például valamilyen valós idejű alkalmazás belső ciklusában. 


A goto kevés értelmes használatának egyike a mindennapi kódban az, hogy kilépünk egy 
beágyazott ciklusból vagy switch utasításból (a break csak a legbelső ciklusból vagy switch 
utasításból lép kD: 


void JO 
( 
int í; 
int j; 
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for Gi - O; izn; it4) 
for ( — 0; jem; jr) if (nmlillj] —— a) goto found; 
// nem található 
Ms 
found: 


7 nmlijlj]) —- a 


j 


A ciklus végére ugró continue utasítás működésével a §6.1.5-ben foglalkoztunk. 


6.4. Megjegyzések és behúzás 


A program olvasását és megértését sokkal kellemesebbé teheti, ha okosan használjuk 
a megjegyzéseket és a behúzást. Számos behúzási stílus használatos és nem látok alapvető 
okot arra, hogy egyiket a másikkal szemben előnyben részesítsük (bár a legtöbb programo- 
zóhoz hasonlóan nekem is van választott stílusom — a könyv nyilván tükrözi is az). Ugyan- 
ez vonatkozik a megjegyzések stílusára is. 


A megjegyzéseket számos módon lehet rosszul használni, ami így nagymértékben rontja 
a program olvashatóságát. A fordítóprogram nem érti a megjegyzések tartalmát, ezért nincs 
mód arra, hogy biztosítsa azt, hogy egy megjegyzés 


[1] értelmes, 
[2] a programmal összhangban álló és 
[3] időszerű legyen. 


Számos program olyan megjegyzéseket tartalmaz, melyek érthetetlenek, félreérthetőek, 
vagy egyszerűen hibásak. A rossz megjegyzések rosszabbak, mint ha egyáltalán nem hasz- 
nálnánk megjegyzést. 


Ha valamit leírhatunk magával a programnyelvvel, akkor tegyük azt, ne megjegyzésben 
említsük meg. Ez az észrevétel az ilyenfajta megjegyzésekre vonatkozik: 


// a "v" váltózónak kezdőértéket kell adni 
// a "v" változót csak az "10" függvény használhatja 


// az "initO" függvényt minden más függvény előtt meg kell hívni ebben a fájlban 
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// a "cleanupO" függvényt meg kell hívni a program végén 
// a "weirdO" függvényt ne használjuk 


// az "10" függvénynek két paramétert kell adni 


A C44 megfelelő használata az ilyen megjegyzéseket általában szükségtelenné teszi. A fen- 
tieket például kiválthatjuk, ha alkalmazzuk az összeszerkesztési (49.2) vagy az osztályokra 
vonatkozó láthatósági, kezdőérték-adási és felszámolási szabályokat (410.4.1). 


Mihelyt valamit világosan leírtunk a nyelvvel, másodszor már nem kell megemlítenünk egy 
megjegyzésben: 


a-btc;  // a-ból bi-c lesz 
count44; // növeljük a számlálót 


Az ilyen megjegyzések még az egyszerűen feleslegeseknél is rosszabbak, mert növelik az 
elolvasandó szöveg hosszát, gyakran összezavarják a program szerkezetét, és lehet, hogy 
hibásak. Meg kell azonban jegyeznünk, hogy az ilyen megjegyzések széleskörűen haszná- 
latosak tanítási célokra az olyan programozási nyelvekről szóló könyvekben, mint amilyen 


ez is. Ez az egyik, amiben egy könyvben lévő program különbözik egy igazi programtól. 
Én a következőket szeretem: 


1. Minden forrásfájlban van megjegyzés, amely leírja, mi a közös a fájlban levő 
deklarációkban, utal a segédanyagokra, általános ötleteket ad a kód módosítá- 
sával kapcsolatban stb. 

2. Minden osztályhoz, sablonhoz és névtérhez tartozik megjegyzés. 

3. Minden nem magától értetődő függvényhez van olyan megjegyzés, amely leírja 
a függvény célját, a felhasznált algoritmust (ha az nem nyilvánvaló), és esetleg 
azt, hogy mit feltételez környezetéről. 

4. Minden globális és névtér-változóhoz, illetve konstanshoz van megjegyzés. 

5. Van néhány megjegyzés ott, ahol a kód nem nyilvánvaló és/vagy más rendszer- 
re nem átültethető. 

6. A fentieken kívül kevés megjegyzés van. 
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Például: 
// tbl.c: Inplementation of the symbol table. 


/£ 
Gaussian elimination with partial bivoting. 
See Ralston: "A first course ..." pg 411. 

47 


// swapO assumes the stack layout of an SGI R6000. 


ÉTÉ AE ök e ake ak e ale lk öle ale ök ök ale akk ale ke öle a ale ék 3k ak kek ekök 


Copyright (c) 1997 AIRT, Inc. 
All rights reserved 


ae le ale ale ale ale ale ale ale ale le jé ale oke ale ale oke ale alk oke alk alk akk alk ak ok ok ak okok ak / 


A jól megválasztott és jól megírt megjegyzések alapvető részét képezik a jó programnak. Jó 
megjegyzéseket írni legalább olyan nehéz, mint megírni magát a programot. Olyan művé- 
szet, melyet érdemes művelni. 


Jegyezzük meg azt is, hogy ha kizárólag a / megjegyzéseket használjuk egy függvényben, 
akkor ennek a függvénynek bármely részét megjegyzésbe tehetjük a /? "/jelöléssel (ez for- 
dítva is igaz). 


6.5. Tanácsok 


[1] Részesítsük előnyben a standard könyvtárat a többi könyvtárral és a , kézzel írt 
kóddal" szemben. §6.1.8. 

[2] Kerüljük a bonyolult kifejezéseket. §6.2.3. 

[3] Ha kétségeink vannak az operátorok precedenciájával kapcsolatban, zárójelez- 
zünk. §46.2.3. 

[4] Kerüljük a típuskényszerítést (cast). 96.2.7. 

[5] Ha explicit típuskonverzió szükséges, részesítsük előnyben a jobban definiált 
konverziós operátorokat a C stílusú átalakítással szemben. §6.2.7. 

[6] Kizárólag jól meghatározott szerkezeteknél használjuk a 7(e) jelölést. §6.2.8. 

[7] Kerüljük az olyan kifejezéseket, melyek kiértékelési sorrendje nem meghatáro- 
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zott. §6.2.2. 

[8] Kerüljük a goto-t. §6.3.4. 

[9] Kerüljük a do utasítást. §6.3.3. 

[10] Ne adjunk meg változót addig, amíg nincs érték, amivel feltölthetnénk. §6.3.1, 
46.3.2.1, §6.3.3.1. 

[11] A megjegyzéseket frissítsük rendszeresen. §6.4. 

[12] Tartsunk fenn következetes stílust. §6.4. 

[13] A globális operator newO helyettesítésére adjunk meg inkább egy operator 
new tagot (§15.06). §6.2.6.2. 

[14] Bemenet beolvasásakor mindig vegyük számításba a rosszul megadott bemene- 
tet is. §6.1.3. 


6.6. Gyakorlatok 


1. (1) Írjuk meg a következő /or utasítással egyenértékű while utasítást: 


for G-0, izmax length; i3) if (input linelíj -— "?) guest count4-; 


Ezt írjuk át úgy, hogy ciklusváltozóként mutatót használunk, azaz úgy, hogy 
a vizsgálat "p-—" alakú legyen. 
2. C1) Zárójelezzük teljesen a következő kifejezéseket: 


a-bictdcc2£B8 
ak 0771/- 3 
a--blla-—c£gkcc5 
c- x/-0 

0£-ic7 

KH1,2-3 
a--14t4b--5 
a-b-—cdr 


a-b-c-0O 
alálla] "—-tb?c:?td?"2 
a-b,c-d 


3. C2) Olvassuk be üreshellyel elválasztott (név- és érték-) párok sorozatát, ahol 
a név egyetlen üreshellyel elválasztott szó, az érték pedig egy egész vagy lebe- 
gőpontos érték. Számítsuk ki és írjuk ki minden névre az értékek összegét és 
számtani közepét, valamint az összes névre vonatkozó összeget és számtani 
közepet. Tipp: §6.1.8. 

4. C1) Írjuk meg a bitenkénti logikai operátorok (46.2.4) értéktáblázatát a 0 és 17 
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operandusok összes lehetséges párosítására. 

5. C1,5) Találjunk 5 különböző C-- szerkezetet, melynek jelentése nem meghatá- 
rozott (4C.2). C1,5.) Találjunk 5 különböző C-- szerkezetet, melynek jelentése 
a nyelvi megvalósítástól függ (4C.2). 

6. C1) Adjunk 10 különböző példát nem hordozható C-t kódra. 

7. (2) Írjunk 5 kifejezést, melyek kiértékelési sorrendje nem meghatározott. Hajt- 
suk őket végre és nézzük meg, mit csinál velük egy — de lehetőleg több — C---- 
változat. 

8. C1,5) Mi történik a rendszerünkben, ha nullával osztunk? Mi történik túlcsordu- 
lás és alulcsordulás esetén? 

9. C1 Zárójelezzük teljesen a következő kifejezéseket: 


XD4A 

tb 

4-Hd-— 
(int)p-2m 
p.m 

kglij 


10. (2) Írjuk meg a következő függvényeket: strlenO, ami egy C stílusú karakter- 
lánc hosszát adja vissza, strcpyO, ami egy karakterláncot másol egy másikba, és 
strcmpO), ami két karakterláncot hasonlít össze. Gondoljuk meg, mi legyen a pa- 
raméterek és a visszatérési érték típusa. Ezután hasonlítsuk össze a függvénye- 
ket a standard könyvtárban lévő változatokkal, ahogy azok a ccstring:-ben 
Csstring.h:-ban) szerepelnek és ahogy a 420.4.1 pontban leírtuk azokat. 


11.C"1 Nézzük meg, hogyan reagál a fordítóprogramunk ezekre a hibákra: 


void f(int a, int b) 


t 
if(a- 3) / ... 
if(ak077 -—- 0) / ... 
a :—- b4 1; 

j 


, Készítsünk" több egyszerű hibát és nézzük meg, hogyan reagál 
a fordítóprogram. 

12. (2) Módosítsuk úgy a §6.6[3] programot, hogy a középső értéket (medián) is ki- 
számítsa. 

13. 2) Írjuk meg a catO függvényt, amelynek két C stílusú karakterlánc paraméte- 
re van és egy olyan karakterláncot ad vissza, amely a paraméterek összefűzé- 
séből áll elő. Az eredményeknek foglaljunk helyet a szexw-val. 

14. C2) Írjuk meg a revO függvényt, amelynek egy karakterlánc paramétere van és 
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megfordítja a benne lévő karaktereket. Azaz a rew(b) lefutása után b utolsó ka- 
raktere az első lesz és így tovább. 
15.C"1,5) Mit csinál a következő példa és miért írna valaki ilyesmit? 


void send(int" to, int" from, int count) 
// Duff programja. A megjegyzéseket szándékosan töröltem. 


( 
int n - (count 7)/8; 
switch (count908) f 
case0: dof 1044 — $from4r; 
case 7: kf04t4 — Xfromt-; 
case G: 1044 — $from4r; 
case 5: 1044 — Ffromt-; 
case 4: kt0t4 - $from4tr; 
case 3: tott — Ffrom4r; 
case 2: $t04t4 — tfrom4r; 
case I: tott — tfrom4t; 

2 while (--n20); 

A 

, 


16. (2) Írjuk meg az atoi(const char?) függvényt, amely egy számokat tartalmazó 
karakterláncot kap és visszaadja a megfelelő egészet. Például atoi("123") 123 
lesz. Módosítsuk az atoi0-t úgy, hogy kezelje a Ct-4 oktális és hexadecimális je- 
lölését is, az egyszerű, tízes számrendszerbeli számokkal együtt. Módosítsuk 
a függvényt úgy is, hogy kezelje a C-t karakterkonstans jelölést is. 

17. (2) Írjunk egy olyan itoa(int i, char b[ J) függvényt, amely létrehozza b-ben i 
karakterlánc ábrázolását és visszaadja D-t. 

18. €2) Gépeljük be teljes egészében a számológép példát és hozzuk működésbe. 
Ne takarítsunk meg időt azzal, hogy már begépelt szövegrészeket használunk. 
A legtöbbet a , kis buta hibák" kijavításából fogunk tanulni. 

19. 2) Módosítsuk a számológépet, hogy kiírja a hibák sorának számát is. 

20.C3) Tegyük lehetővé, hogy a felhasználó függvényeket adhasson meg a számo- 
lógéphez. Tipp: adjunk meg egy függvényt műveletek sorozataként, úgy, mint- 
ha a felhasználó gépelte volna be azokat. Az ilyen sorozatokat karakterláncként 
vagy szimbólumok (tokenek) listájaként tárolhatjuk. Ezután olvassuk be és hajt- 
suk végre ezeket a műveleteket, amikor a függvény meghívódik. Ha azt akar- 
juk, hogy egy felhasználói függvénynek paraméterei legyenek, akkor arra külön 
jelölést kell kitalálnunk. 

21.C"1,5) Alakítsuk át a számológépet, hogy a symbol szerkezetet használja és ne 
a statikus number. value és string value változókat. 

22.(t2,5) Írjunk olyan programot, amely kiveszi a megjegyzéseket a C4-- progra- 
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mokból. Azaz, olvassunk a cin-ről, távolítsuk el mind a // mind a /t §/ megjegy- 
zéseket, majd írjuk ki az eredményt a cout-ra. Ne törődjünk azzal, hogy a kime- 
net szép legyen (az egy másik, sokkal nehezebb feladat lenne). Ne törődjünk 
a hibás programokkal. Óvakodjunk a // /? és §/ használatától a megjegyzések- 
ben, karakterláncokban és karakterkonstansokban. 

23. (2) Nézzünk meg néhány programot, hogy elképzelésünk lehessen a mostanság 
használatos stílusok (behúzások, elnevezések és megjegyzések) változatosságáról. 


Függvények 


, Ismételni emberi dolog. 
Rekurziót írni isteni." 
(1. Peter Deutsch) 


Függvénydeklarációk és -definíciók s Paraméterátadás e Visszatérési értékek s Függvény- 
túlterhelés e A többértelműség feloldása e Alapértelmezett paraméterek e sidargs " Függ- 
vényekre hivatkozó mutatók s Makrók s Tanácsok s Gyakorlatok 


7.1. Függvénydeklarációk 


A C44-ban általában úgy végzünk el valamit, hogy meghívunk rá egy függvényt, és a függ- 
vény definiciójával írjuk le, hogyan kell azt elvégezni. A függvényt azonban nem hívhatjuk 
meg úgy, hogy előzetesen nem deklaráltuk. A függvény deklarációja megadja a függvény 
nevét, visszatérési értékének típusát (ha van ilyen), és azon paraméterek számát és típusát, 
amelyeket át kell adni a függvény meghívásakor: 


Elem? next elemO; 
char" strecpy(char? to, const char" from); 
void exit(inD); 


192 Alapok 


A paraméterátadás ugyanazt a szerepet tölti be, mint a kezdeti értékadás. A fordítóprogram 
ellenőrzi a paraméterek típusát és automatikus típuskonverziót végez, ha szükséges: 


double sgrt(double); 
double sr2 -— sgrt(29; // sgrtÖ0 meghívása double(2) paraméterrel 
double sg3 -— sgrt("three"); " // hiba: sgrtO double típusú baramétert igényel 


Az ilyen ellenőrzés és konverzió jelentőségét nem szabad alábecsülni. 


A függvénydeklaráció paraméterneveket is tartalmazhat, melyek segítik a program olvasó- 
ját. A fordítóprogram ezeket egyszerűen nem veszi figyelembe. Amint §4.7-ben említettük, 
a void visszatérési típus azt jelenti, hogy a függvény nem ad vissza értéket. 


7.1.1. Függvénydefiníciók 
Minden függvényt, amit meghívunk a programban, valahol (de csak egyszer) meg kell ha- 


tároznunk. A függvénydefiníció (függvény-meghatározás) olyan deklaráció, amelyben 
megadjuk a függvény törzsét: 


extern void swap(int", int"); // deklaráció 
void swap(int? p, intt 9) // definíció 
( 

int t — tp; 

kp — tg; 

kg sz t; 


J 


A függvények definícióinak és deklarációinak ugyanazt a típust kell meghatározniuk. A pa- 
raméterek nevei azonban nem részei a típusnak, így nem kell azonosaknak lenniük. 


Nem ritka az olyan függvénydefiníció, amely nem használja fel az összes paramétert: 


void search(table" t, const char" key, const char") 


// a harmadik paraméter nem használatos 


j 
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Amint látjuk, azt a tényt, hogy egy paramétert nem használunk fel, úgy jelölhetjük, hogy 
nem nevezzük meg a paramétert. A névtelen paraméterek jellemzően a program egyszerű- 
sítése folytán vagy annak későbbi bővíthetőségét biztosítandó kerülnek a kódba. Mindkét 
esetben azzal, hogy bár nem használjuk fel, de a helyükön hagyjuk a paramétereket, bizto- 


sítjuk, hogy a függvényt meghívókat nem érintik a módosítások. 
A függvényeket a fordító által a hívás sorában kifejtendőként Cinline-ként) is megadhatjuk: 


inline int fac(int n) 


return (n22) ? 1 : nyfac(n-1; 


J 


Az inline kulcsszó javaslat a fordítóprogram számára, hogy a facO) meghívásánál próbálja 
meg annak kódját a hívás sorában létrehozni, ahelyett, hogy előbb létrehozná azt, majd 
a szokásos függvényhívó eljárás szerint hívná meg. Egy okos fordítóprogram a jfac(6) 
meghívásakor létre tudja hozni a 720 konstanst. Az egymást kölcsönösen meghívó (kölcsö- 
nösen rekurzív) helyben kifejtett függvények, illetve a bemenettől függően magukat újrahí- 
vó vagy nem újrahívó helyben kifejtett függvények lehetősége miatt nem biztos, hogy egy 
inline függvény minden hívása a hívás sorában jön létre. A fordítóprogramok intelligenciá- 
jának mértéke nem írható elő, így előfordulhat, hogy az egyik 720-at, a másik 6"fac(59-öt, 
a harmadik pedig a /ac(6) nem helyben kifejtett hívást hozza létre. 


Ha nem rendelkezünk kivételesen intelligens fordító- és szerkesztő-programmal, a hívás so- 
rában történő létrehozást akkor biztosíthatjuk, ha a függvény kifejtése — és nem csak dek- 
larációja — is a hatókörben szerepel (49.29. Az inline kulcsszó nem befolyásolja a függvény 
értelmezését. Nevezetesen az ilyen függvényeknek — és static változóiknak (§7.1.2.) is 


— ugyanúgy egyedi címük van. 


7.1.2. Statikus változók 


A lokális (helyi) változók akkor kapnak kezdőértéket, amikor a végrehajtás elér a definiciójuk- 
hoz. Alapértelmezés szerint ez a függvény minden meghívásakor megtörténik, az egyes függ- 
vényhívásoknak pedig saját másolatuk van a változóról. Ha egy lokális változót static-ként ve- 
zetünk be, akkor azt a függvény minden meghívásakor egyetlen, állandó című objektum jelö- 
li majd. A változó csak egyszer kap értéket, amikor a végrehajtás eléri annak első definícióját: 
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void f(int a) 
( 
while (a--) ( 
staticintn 7 0;  // egyszer kap kezdőértéket 
int x — 0; // "a! alkalommal kap kezdőértéket (az f0 minden meghívásakor) 
cout c n-— "az nti cc" x—-— "aZ xtt Mt 
J 


J 


int mainO 


( 
H39; 
4 


J 


A fenti a következőket írja ki: 


n-- 0, x--0 
n -- 1, x--0 
n-- 2 x--0 


A statikus változók anélkül biztosítanak , emlékezetet" a függvénynek, hogy globális válto- 
zót vezetnének be, amelyet más függvények is elérhetnek és módosítással használhatatlan- 
ná tehetnek (lásd még §10.2.4). 


7.2. Paraméterátadás 


Amikor egy függvény meghívódik, a fordítóprogram a formális paraméterek számára tárte- 
rületet foglal le, az egyes formális paraméterek pedig a megfelelő valódi (aktuális) paramé- 
ter-értékkel töltődnek fel. A paraméterátadás szerepe azonos a kezdeti értékátadáséval. 
A fordítóprogram ellenőrzi, hogy az aktuális paraméterek típusa megegyezik-e a formális 
paraméterek típusával, és végrehajt minden szabványos és felhasználói típuskonverziót. 
A tömbök átadására egyedi szabályok vonatkoznak (§7.2.1), de van lehetőség nem ellenőr- 
zött (47.6) és alapértelmezett paraméterek (§7.5) átadására is. Vegyük a következő példát: 


void f(int val, intik ref) 
( 

valt; 

reftr; 


j 
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Amikor 10 meghívódik, val-4- az első aktuális paraméter helyi másolatát növeli, reff- pe- 
dig a második aktuális paramétert. Az alábbi 


void gO 

f 
inti — 1; 
int j— [; 
ÍGY; 

J 


j-t fogja növelni, de í-t nem. Az első paraméter (Öö érték szerint adódik át, a második ()) re- 
ferencia szerint. Amint §5.5-ben említettük, azok a függvények, melyek módosítják a refe- 
rencia szerint átadott paramétereiket, nehezen olvashatóvá teszik a programot és általában 
kerülendők (ellenben lásd §21.3.2-et). Észrevehetően hatékonyabb lehet, ha egy nagy ob- 
jektumot referencia, nem pedig érték szerint adunk át. Ebben az esetben a paramétert 
megadhatjuk const-ként, hogy jelezzük, csak hatékonysági okokból használunk referenciát 
és nem szeretnénk lehetővé tenni, hogy a hívott függvény módosíthassa az objektum érté- 
két: 


void fconst Largek arg) 


( 


// "arg" értéke nem módosítható, csak explicit típuskonverzióval 


J 


ban áll a változót módosítani: 


void g(Largek arg); // tételezzük fel, hogy g0 módosítja arg-ot 


Hasonlóan, a const-ként megadott mutató paraméter azt jelzi az olvasónak, hogy a paramé- 
ter által mutatott objektum értékét a függvény nem változtatja meg: 


int strlenCcconst char? ); // karakterek száma egy C stílusú 
// karakterláncban 
char" strepy(char? to, const char" from); // C stílusú karakterlánc másolása 
int stremp(const char", const char"); // GC stílusú karakterláncok összehasonlítása 


A const paraméterek használatának fontossága a program méretével együtt nő. 


Jegyezzük meg, hogy a paraméterátadás szerepe különbözik a (nem kezdeti) értékadásétól. 
Ez a const paraméterek, a referencia-paraméterek, és néhány felhasználói típusú paraméter 
esetében lényeges (410.4.4.1). 
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Literált, állandót és olyan paramétert, amely átalakítást igényel, át lehet adni constát para- 
méterként, de nem constk-ként nem. Mivel a const 1£k paraméterek konverziója megenge- 
dett, biztosított, hogy egy ilyen paraméternek pontosan ugyanazokat az értékeket lehet 
adni, mint egy 7 típusú értéknek, azáltal, hogy az értéket ideiglenes változóban adjuk át 
(amennyiben ez szükséges): 


float fsgrt(const float£ ); // Fortran stílusú sgrt referencia-baraméterrel 


void g(double d) 
( 


float r - fsgrt(2.OP); // a 2.0f-et tartalmazó ideiglenes változóra hivatkozó 
// referencia átadása 
r - fsgrt(r); // r-re hivatkozó referencia átadása 
r - fsgrt(d); , // a float(d)-t tartalmazó ideiglenes változóra hivatkozó referencia 
// átadása 
j 
Mivel a nem const referencia típusú paraméterek konverziója nem megengedett, az ideig- 


lenes változók bevezetéséből adódó buta hibák elkerülhetők: 


void update(floatk ij; 
void g(double d, float r) 


update(2.OP); // hiba: konstans paraméter 
update(r9; // r-re hivatkozó referencia átadása 


update(d); // hiba: típuskonverzió szükséges 


j 


Ha ezek a hívások szabályosak lennének, az update csendben módosította volna azokat 


az ideiglenes változókat, amelyek azonnal törlődtek. Ez rendszerint kellemetlen meglepe- 
tésként érné a programozót. 


7.2.1. Tömb paraméterek 


Ha függvényparaméterként tömböt használunk, a tömb első elemére hivatkozó mutató 
adódik át: 


int strlenCcconst char? ); 


void JO 


char ul ] - "egy tömb"; 
int i — strlen(v); 
int j — strlen("Nicholas"); 


j 
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Azaz egy 1//Jtípusú paraméter 7" típusúvá lesz alakítva, ha paraméterként adódik át. Ebből 
az következik, hogy ha egy paraméterként alkalmazott tömb egy eleméhez értéket rende- 
lünk, a tömb paraméter is módosul, vagyis a tömbök abban különböznek a többi típustól, 
hogy nem érték szerint adódnak át (ez nem is lehetséges). 


A tömb mérete nem hozzáférhető a hívott függvény számára. Ez bosszantó lehet, de több 
mód van rá, hogy a problémát megkerüljük. A C stílusú karakterláncok nulla végződésűek, 
így méretük könnyen kiszámítható. Más tömböknél a méretet egy további paraméterrel ad- 
hatjuk meg: 


void compbuteI(int? vec ptr, int vec size); // egyik módszer 


struct Vec ( 
int ptr; 
int size; 


J; 
void compute2(const Vec£ v); // másik módszer 
Választhatjuk azt is, hogy tömbök helyett olyan típusokat használunk, mint a vector (§3.7.1, 


§16.39. A többdimenziós tömbök némileg bonyolultabbak (ásd §C.7), de helyettük gyakran 
használhatunk mutatókból álló tömböket, melyek nem igényelnek különleges bánásmódot: 


char" da( ] -( 


"hétfő", "kedd", "szerda", "csütörtök", "péntek", "szombat", "vasárnap" 


); 


A vector és a hozzá hasonló típusok a beépített, alacsonyszintű tömbök és mutatók helyett 
is használhatók. 


7.3. Visszatérési érték 


A mainO kivételével(§43.2) minden nem void-ként megadott függvénynek értéket kell 
visszaadnia. Megfordítva, a void függvények nem adhatnak vissza értéket: 


int fIO ( ; // hiba: nincs visszatérési érték 
void [20 ( ? // rendben 
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int f30 ( return 1; ) // rendben 

void [40 f return I; ) // hiba: visszatérési érték void függvényben 
int f50 f return; ? // hiba: visszatérési érték hiányzik 

void 160 ( return; ) // rendben 


A visszatérési értéket a return utasítás határozza meg: 


int fac(int n) ( return (n:1) ? n?fac(n-1) : IT; ) 


Az önmagukat meghívó függvényeket rekurzív Cújrahívó) függvényeknek nevezzük. 
Egy függvényben több return utasítás is lehet: 


int fac2X(int n) 


( 
if (n : 1) return n"fjacXn-1); 


return 1; 
? 


af 
A paraméterátadáshoz hasonlóan a függvényérték visszaadásának szerepe is azonos a kez- 
deti értékadáséval. A return utasítást úgy tekintjük, hogy az egy visszatérési típusú, név nél- 


küli változónak ad kezdőértéket. A fordítóprogram összehasonlítja a return kifejezés típu- 
sát a visszatérési típussal és minden szabványos és felhasználói típusátalakítást végrehajt: 


double f0 ( return 1; ) // 1 automatikusan doubleC1)-gyé alakul 


Minden egyes alkalommal, amikor egy függvény meghívódik, paramétereinek és lokális 
(automatikus) változóinak egy új másolata jön létre. A tár a függvény visszatérése után is- 
mét felhasználásra kerül, ezért lokális változóra hivatkozó mutatót soha nem szabad vissza- 
adni, mert a mutatott hely tartalma kiszámíthatatlan módon megváltozhat: 


int" fpO f int local — 1; /? ... "/ return local; )  // rossz 


Ez a hiba kevésbé gyakori, mint referenciát használó megfelelője: 


intik frÓ ( int local — 1; /? ... "/ return local; ) . / rossz 


Szerencsére a fordítóprogram általában figyelmeztet, hogy lokális változóra vonatkozó hi- 
vatkozást adtunk vissza. 
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A void függvények nem adhatnak vissza értéket, de meghívásuk nem is eredményez ilyet, 
következésképpen egy void függvény return utasításában szereplő kifejezésként használ- 
hatunk void függvényt: 


void gCint" p); 


Ez a fajta visszatérés olyan sablon (template) függvények írásánál fontos, ahol a visszatéré- 
si típus egy sablonparaméter (lásd §18.4.4.2). 


7.4. Túlterhelt függvénynevek 


A legtöbb esetben jó ötlet különböző függvényeknek különböző neveket adni, de amikor 
egyes függvények lényegében ugyanazt a műveletet végzik különböző típusú objektumo- 
kon, kényelmesebb lehet ugyanúgy elnevezni azokat. Azt, hogy különböző típusokra vo- 
natkozó műveletekre ugyanazt a nevet használjuk, tűlterhelésnek (overloading) nevezzük. 
Ez a módszer a Ct4 alapműveleteinél is használatos. Azaz, csak egyetlen , név" van az 
összeadásra (73), az mégis használható egész, lebegőpontos, és mutató típusú értékek 
összeadására is. A gondolatot a programozó által készített függvényekre is kiterjeszthetjük: 


void print(inD); // egész kiírása 
void print(const char"); // C stílusú karakterlánc kiírása 


Ami a fordítóprogramot illeti, az egyetlen, ami közös az azonos nevű függvényekben, 
a név. A függvények feltehetően hasonlóak valamilyen értelemben, de a nyelv nem korlá- 
tozza és nem is segíti a programozót. Ezért a túlterhelt függvénynevek elsődlegesen jelölés- 
beli kényelmet adnak. Ez a kényelem az olyan hagyományos nevű függvényeknél igazán 
lényeges, mint az sgrt, print, és open. Amikor a név jelentése fontos, ez a kényelem alapve- 
tővé válik. Ez történik például a 4, " és c operátorok, a konstruktorok (411.7), valamint az 
általánosított (generikus) programozás (42.7.2, 18. fejezet) esetében. Amikor egy ffüggvény 
meghívódik, a fordítóprogramnak ki kell találnia, melyik fnevű függvényt hívja meg. Ezt 
úgy teszi, hogy minden egyes fnevű függvény formális paramétereinek típusát összehaso- 
nítja az aktuális paraméterek típusával, majd azt a függvényt hívja meg, amelynek paramé- 
terei a legjobban illeszkednek, és fordítási idejű hibát ad, ha nincs jól illeszkedő függvény: 
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void print(double); 

void print(long); 

void JO 

( 
print(1D; // print(long) 
print(1.09; // print(double) 


brint( 1; // hiba, többértelmű: print(long(1)) vagy print(doubleC1))? 
2 


J 


A fordítóprogram a túlterhelt függvények halmazából úgy választja ki a megfelelő változa- 
tot, hogy megkeresi azt a függvényt, amelyiknél a hívás paraméter-kifejezésének típusa 
a legjobban illeszkedik a függvény formális paramétereire. Ahhoz, hogy mindez elvárása- 
inknak (közelítően) megfelelő módon történjen, az alábbiakat kell megkísérelni (ebben 
a sorrendben): 


1. Pontos illeszkedés: nincs szükség konverzióra vagy csak egyszerű konverziókat 
kell végezni (például tömb nevét mutatóra, függvény nevét függvényre hivatko- 
zó mutatóra, vagy T-t const Tre). 

2. Kiterjesztést használó illeszkedés: csak egész értékre kiterjesztés (integral 
promotion) szükséges (bool-ról int-re, char-ról int-re, short-ról int-re, illetve 
ezek unsigned megfelelőiről int-re §C.6.1), valamint float-ról double-ra. 

3. Szabványos konverziókat használó illeszkedés: int-ről double-ra, double-ról int- 
re, Derived"-ról Base"-ra (§12.2), T"-ról void"-ra (45.60), vagy int-ről unsigned 
int-re (§C.0). 

4. Felhasználói konverziókat használó illeszkedés (§11.4). 

5. Függvénydeklarációban három pontot C(. ..) használó illeszkedés (47.06). 


Ha azon a szinten, ahol először találunk megfelelő illeszkedést, két illeszkedést is találunk, 
a hívást a fordító többértelműként elutasítja. A túlterhelést feloldó szabályok elsősorban 
azért ennyire alaposan kidolgozottak, mert figyelembe kellett venni a C és a Cst beépített 
numerikus típusokra vonatkozó bonyolult szabályait (§C.6). Vegyük a következő példát: 


void printGnV); 

void print(const char"); 
void print(double); 
void print(long); 

void print(char); 


void h(char c, int i, short s, float f) 

( 
print(c9; // pontos illeszkedés: print(char) meghívása 
print ); // pontos illeszkedés: print(int) meghívása 
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bprint(59; // kiterjesztés egésszé: print(int) meghívása 
print; // float kiterjesztése double-lé: print(double) 
bprintCa); // pontos illeszkedés: print(char) meghívása 
brint(49); // pontos illeszkedés: print(int) meghívása 
print(09; // pontos illeszkedés: print(int) meghívása 
brint("a"); // pontos illeszkedés: print(const char?) meghívása 


A print(0) hívás a print(int9-et hívja meg, mert 0 egy int. A print(a)) hívás a print(char)-t, 
mivel a! egy char (§4.3.1. Az átalakítások (konverziók) és a kiterjesztések között azért 
teszünk különbséget, mert előnyben akarjuk részesíteni a biztonságos kiterjesztéseket (pél- 
dául char-ról int-re) az olyan, nem biztonságos műveletekkel szemben, mint az int-ről 
char-ra történő átalakítás. 


A túlterhelés feloldása független a szóba jöhető függvények deklarációs sorrendjétől. 


A túlterhelés viszonylag bonyolult szabályrendszeren alapul, így a programozó néha meg- 
lepődhet azon, melyik függvény hívódik meg. Ez azonban még mindig a kisebbik rossz. Ve- 
gyük figyelembe a túlterhelés alternatíváját: gyakran hasonló műveleteket kell végrehajta- 
nunk többféle típusú objektumon. Túlterhelés nélkül több függvényt kellene megadnunk, 
különböző nevekkel: 


void print. int(Gint); 
void print charCchar); 
void print string(const char"); // GC stílusú karakterlánc 


void g(int i, char c, const char" p, double d) 


( 
print int(i); // rendben 
print char(c); // rendben 
brint string(p); // rendben 
print int(c9; // rendben? print int(int(c)) meghívása 
brint char(); // rendben? print char(char(i)) meghívása 
brint string(i); // hiba 
brint int(d); // rendben? print. int(int(d)) meghívása 
J 


A túlterhelt printO-hez képest több névre és arra is emlékeznünk kell, hogy a neveket he- 
lyesen használjuk. Ez fárasztó lehet, meghiúsítja az általánosított programozásra (§2.7.2) irá- 
nyuló erőfeszítéseket, és általában arra ösztönzi a programozót, hogy viszonylag alacsony 
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szintű típusokra irányítsa figyelmét. Mivel nincs túlterhelés, ezen függvények paraméterein 
bármilyen szabványos konverziót elvégezhetünk, ami szintén hibákhoz vezethet. Ebből az 
következik, hogy a fenti példában a négy , hibás" paraméterrel való hívás közül csak egyet 
vesz észre a fordítóprogram. A túlterhelés növeli annak az esélyét, hogy egy nem megfele- 
lő paramétert a fordítóprogram elutasít. 


7.4.1. A túlterhelés és a visszatérési típus 


A túlterhelés feloldásánál a visszatérési típust nem vesszük figyelembe. Ez azért szükséges, 
hogy az egyes operátorokra (411.2.1, §11.2.4) vagy függvényhívásra vonatkozó feloldás kör- 
nyezetfüggetlen maradjon. Vegyük a következőt: 


float sgrt(floa); 

double sgrt(double); 

void (double da, float fla) 

( 
float fl - sgrt(da); // sgrt(double) meghívása 
double d - sgrt(da); // sgrtídouble) meghívása 
JJ - sgrt(fla; // sgrt(float) meghívása 
d - sgrt(fla); // sgrt(float) meghívása 


j 


Ha a visszatérési típust a fordítóprogram figyelembe venné, többé nem lenne lehetséges, 
hogy elszigetelten nézzük az sgrtO egy hívását és eldöntsük, azzal melyik függvényt hívták 
meg. 


7.4.2. A túlterhelés és a hatókör 


A különböző, nem névtér hatókörben megadott függvények nem túlterheltek: 
void fin; 
void gO 
void (double); 


KV; // double) meghívása 
? 


J 
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Világos, hogy ((in0) lett volna a legjobb illeszkedés /(10-re, de a hatókörben csak f[double) 
látható. Az ilyen esetekben helyi deklarációkat adhatunk a kódhoz vagy törölhetjük azokat, 
hogy megkapjuk a kívánt viselkedést. Mint mindig, a szándékos elfedés hasznos módszer 
lehet, a nem szándékos azonban meglepetéseket okozhat. Ha osztály-hatókörök (415.2.2) 
vagy névtér-hatókörök (48.2.9.2) között átnyúló túlterhelést szeretnénk, using deklaráció- 
kat vagy using utasításokat használhatunk (48.2.2). Lásd még §8.2.6-ot. 


7.4.3. A többértelműség , kézi" feloldása 


Többértelműséghez vezethet, ha egy függvénynek túl sok (vagy túl kevés) túlterhelt válto- 
zatát adjuk meg: 


void fi(char); 
void f1(ong); 


void f2(char?); 
void f2GNtP?J; 


void k(int i) 
JG; // többértelmű: fi(char) vagy f1(long) 
J2CO;  / többértelmű: f2Xchar?) vagy f2Cinr) 
) 


Ahol lehetséges, az ilyen esetekben úgy kell tekintsük egy függvény túlterhelt változatainak 
halmazát, mint egészet, és gondoskodnunk kell róla, hogy a változatok azonos értelműek 
legyenek. Ez többnyire úgy oldható meg, ha a függvénynek egy olyan új változatát adjuk 
hozzá az eddigiekhez, amely feloldja a többértelműséget: 


inline void fI(int n) ( fidong(n)9; ) 


A fenti függvényváltozat hozzáadása feloldja az összes f1()-hez hasonló többértelműséget 
a szélesebb /ong int típus javára. 


A hívások feloldására típuskényszerítést is használhatunk: 
jf2(static castzintt3(0)); 


Ez azonban általában csúnya és ideiglenes szükségmegoldás, hiszen a következő — hama- 
rosan bekövetkező - hasonló függvényhívással ismét foglalkoznunk kell majd. 
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Néhány kezdő C--- programozót bosszantanak a fordítóprogram által kiírt többértelműségi 
hibák, a tapasztaltabbak viszont becsülik ezeket az üzeneteket, mert hasznos jelzői a terve- 
zési hibáknak. 


7.4.4. Több paraméter feloldása 


A túlterhelést feloldó szabályok alapján biztosíthatjuk, hogy a legegyszerűbb algoritmus 
(függvény) lesz felhasználva, amikor a számítások hatékonysága és pontossága jelentősen 
különbözik a szóban forgó típusoknál: 


int pou(int, int); 
double pouw(double, double); 


complex pouw(double, complex); 
complex pou(complex, int); 
complex pou(complex, double); 
complex pou(complex, complex); 


void k(complex 2) 

( 
int i -— pow(2, 29; // powCint, int) meghívása 
double d - pow(2.0, 2.09; // pow(double, double) meghívása 
complex 22 - pou(2,2); // pow(double, complex) meghívása 
complex 23 - pou(z, 29; // pou(complex, int) meghívása 
complex z4 - pou(z, 2); // pou(complex, complex) meghívása 


A kettő vagy több paraméterű túlterhelt függvények közötti választás folyamán minden pa- 
raméterre kiválasztódik a legjobban illeszkedő függvény, a §7.4 szabályai alapján. Az 
a függvény hívódik meg, amely az adott paraméterre a legjobban, a többire pedig jobban 
vagy ugyanúgy illeszkedik. Ha nem létezik ilyen függvény, a hívást a fordító többértelmű- 
ként elutasítja: 


void g0 


double d - pow(2.O,29; // hiba: powC(int(2.0), 2) vagy pow(2.O, double(29)? 


J 


A függvényhívás azért többértelmű, mert a bow (double, double) első paraméterére 2.0, 
a pow(int, int) második paraméterére pedig 2 a legjobb illeszkedés. 
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7.5. Alapértelmezett paraméterek 


Egy általános függvénynek általában több paraméterre van szüksége, mint amennyi az egy- 
szerű esetek kezeléséhez kell. Nevezetesen az objektumokat (410.2.3) létrehozó függvé- 
nyek gyakran számos lehetőséget nyújtanak a rugalmasság érdekében. Vegyünk egy függ- 
vényt, amely egy egészt ír ki. Ésszerűnek látszik megadni a felhasználónak a lehetőséget, 
hogy meghatározza, milyen számrendszerben írja ki a függvény az egészt, a legtöbb prog- 
ram azonban az egészeket tízes számrendszer szerint írja ki. Például a 


void print(int value, int base -10);  // az alapértelmezett alap 10 


void JO 

( 
brint(3 1; 
Drimt(31,10); 
brint(31,109; 
brint(31,29; 

J 


ezt a kimenetet eredményezheti: 


31 31 17 11111 


Az alapértelmezett (defaul) paraméter hatását elérhetjük túlterheléssel is: 


void print(int value, int base); 
inline void print(int value) ( print(value, 109; ? 


A túlterhelés viszont kevésbé teszi nyilvánvalóvá az olvasó számára, hogy az a szándékunk, 
hogy legyen egy egyszerű print függvényünk és egy rövidítésünk. 


Az alapértelmezett paraméter típusának ellenőrzése a függvény deklarációjakor történik és 
a paraméter a függvény hívásakor értékelődik ki. Alapértelmezett értékeket csak a záró pa- 
ramétereknek adhatunk: 


int f(int, int -O, char" -0);  // rendben 
int g(int -O, int —-O, char");  // hiba 
int h(int -O, int, char? -0); // hiba 
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Jegyezzük meg, hogy a " és az — közötti szóköz lényeges (a "— értékadó operátor, 96.29: 
int nasty(char"-0); // szintaktikus hiba 


Az alapértelmezett paraméterek ugyanabban a hatókörben egy későbbi deklarációval nem 
ismételhetők meg és nem módosíthatók: 


void (int x - 7); 


void fint — 7); // hiba: az alapértelmezett baraméter nem adható meg kétszer 
void fint - 89; // hiba: különböző alapértelmezett paraméterek 
void g0 
( 
void (int x - 9); // rendben: ez a deklaráció elfedi a külsőt 
Ms 


J 


Hibalehetőséget rejt magában, ha egy nevet úgy adunk meg egy beágyazott hatókörben, 


7.6. Nem meghatározott számú paraméter 


Néhány függvény esetében nem határozható meg a hívásban elvárt paraméterek száma és 
típusa. Az ilyen függvényeket úgy adhatjuk meg, hogy a paraméter-deklarációk listáját a .. . 
jelöléssel zárjuk le, melynek jelentése , és talán néhány további paraméter": 


int printf(const char" ...); 


A fenti azt határozza meg, hogy a C standard könyvtárának printfO függvénye (421.8) 
meghívásakor legalább egy char" típusú paramétert vár, de lehet, hogy van más paraméte- 
re is: 


brintfC Helló, világNm"); 
brintfC4A nevem 9os gon", vezetek nev, kereszt nev); 
brintf9ed 4 96d - 9dw,2,3,59; 
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Az ilyen függvények olyan adatokra támaszkodnak, amelyek nem elérhetők a fordítóprog- 
ram számára, amikor az a paraméterek listáját értelmezi. A printfO esetében az első para- 
méter egy formátum-vezérlő, amely egyedi karaktersorozatokat tartalmaz, lehetővé téve, 
hogy a printfO helyesen kezelje a többi paramétert: a 965 például azt jelenti, hogy , várj egy 
char" paramétert", a 90d pedig azt, hogy , várj egy int paramétert". A fordítóprogram viszont 
általában nem tudhatja (és nem is biztosíthatja), hogy a várt paraméterek tényleg ott van- 
nak és megfelelő típusúak-e: 


finclude cstdio.h: 


int mainŐ 


( 
brintfCA nevem 968 909", 29; 


J 


A fenti kódot a fordító lefordítja és (a legjobb esetben) furcsának látszó kimenetet hoz lét- 
re. (Próbáljuk ki) 


Természetesen ha egy paraméter nem deklarált, a fordítóprogram nem fog elegendő infor- 
mációval rendelkezni a szabványos típusellenőrzés és -konverzió elvégzéséhez. Ebben az 
esetben egy s/ort vagy egy char int-ként adódik át, egy float pedig double-ként, a progra- 
mozó pedig nem feltétlenül ezt várja. 


Egy jól megtervezett programban legfeljebb néhány olyan függvényre van szükség, mely- 
nek paraméterei nem teljesen meghatározottak. A túlterhelt vagy alapértelmezett paraméte- 
reket használó függvények arra használhatók, hogy megoldják a típusellenőrzést a legtöbb 
olyan esetben, amikor a paraméterek típusát szükségből meghatározatlanul hagyjuk. A há- 
rom pont csak akkor szükséges, ha a paraméterek száma és típusa is változik. Leggyakrab- 
ban akkor használjuk, amikor olyan C könyvtári függvényekhez készítünk felületet, 
amelyek még nem használják ki a C4- által nyújtott újabb lehetőségeket: 


int fprintfFILE", const char" ...); // a ccstdio: fejállományból 
int execkconst char" ...); // UNIX fejállományból 


A ccstdarg? fejállományban szabványos makrókat találunk, melyekkel hozzáférhetünk az 
ilyen függvények nem meghatározott paramétereihez. Képzeljük el, hogy egy olyan hiba- 
függvényt írunk, amelynek van egy egész paramétere, ami a hiba súlyosságát jelzi, és ezt 
tetszőleges hosszúságú (több karakterláncból álló) szöveg követi. Elképzelésünk az, hogy 
úgy hozzuk létre a hibaüzenetet, hogy minden szót külön karakterlánc paraméterként 
adunk át. Ezen paraméterek listáját egy c/iar-ra hivatkozó , nullpointer" kell, hogy lezárja: 
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extern void errorGint ...); 
extern char" itoa(int, charl DD); // lásd §6.6.[17] 


const char? Null cp — O; 


int main(int argc, char? argul )) 


(t 
switch (argc) f 
case I: 
error(O, argulol Null. cp); 
break; 
case 2: 
error(O, argul0J, argul 1], Null. cp); 
break; 
default: 
char bujferls]; 
errorC1, argul0], "with" itoaCargc-1, buffer), "arguments", Null cp); 
J 
MZGPES 
J 


Az itoaO azt a karakterláncot adja vissza, amelyik a függvény egész típusú paraméterének 
felel meg. 


Vegyük észre, hogy ha a O egész értéket használtuk volna befejezésként, a kód nem lett vol- 
na hordozható: néhány nyelvi megvalósítás a nulla egészt és a nulla mutatót (nullpointer) 
nem azonos módon ábrázolja. Ez a példa szemlélteti a nehézségeket és azt a többletmun- 
kát, amellyel a programozó szembenéz, amikor a típusellenőrzést , elnyomja" a három pont. 


A hibafüggvényt így adhatjuk meg: 


void errorGint severity ...) // a "severity" (súlyosság) után nullával lezárt char?-ok 
// következnek 
( 
va list ap; 
va start(ap,severity); // kezdeti paraméterek 
for Gt 


char? p - va arg(ap,char?); 
if (p -- 0) break; 
cerr ££ p cc! ; 


j 
va end(ap); // paraméterek visszaállítása 


cerr 2 Mi; 


if (severity) exit(severity); 


J 
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Először meghatározzuk a wa list-et és a va start0 meghívásával értéket adunk neki. 
A va start makró paraméterei a va list neve és az utolsó formális paraméter neve. 
A va argO makrót arra használjuk, hogy sorba rendezzük a nem megnevezett paramétere- 
ket. A programozónak minden egyes híváskor meg kell adnia egy típust; a va argO felté- 
telezi, hogy ilyen típusú aktuális paraméter került átadásra, de általában nincs mód arra, 
hogy ezt biztosítani is tudja. Mielőtt még visszatérnénk egy olyan függvényből, ahol 
a va startO-ot használtuk, meg kell hívnunk a va endO-et. Ennek az az oka, hogy 
a va startÖ úgy módosíthatja a vermet, hogy a visszatérést nem lehet sikeresen véghezvin- 
ni. A va endŐ helyreállítja ezeket a módosításokat. 


7.7. Függvényre hivatkozó mutatók 


A függvényekkel csak két dolgot csinálhatunk: meghívhatjuk őket és felhasználhatjuk a cí- 
müket. Amikor a függvény címét vesszük, az így kapott mutatót használhatjuk arra, hogy 
meghívjuk a függvényt: 


void errorCstring 5) €/? ... "/) 


void (tefcU(string); // mutató függvényre 
void JO 
( 
efct - kerror; // efct az error függvényre mutat 
efct( "error"; // error meghívása efct-n keresztül 
J 


A fordítóprogram rá fog jönni, hogy e/fct egy mutató és meghívja az általa mutatott függ- 
vényt. Azaz, egy függvényre hivatkozó mutatót nem kötelező a " operátorral feloldanunk. 
Ugyanígy nem kötelező a £ használata sem a függvény címének lekérdezésére: 


void CfUdGstring) - kerror; . // rendben 


void €f29(string) -— error;  // ez is jó; jelentése ugyanaz, mint az kerror-nak 
void g0 

jiCVvasa"),; // rendben 

CfDCMary Rose"); // ez is jó 


A függvényekre hivatkozó mutatók paramétereinek típusát ugyanúgy meg kell adnunk, 
mint a függvényeknél. A mutatókat használó értékadásokban ügyelni kell a teljes függvény 
típusára: 
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void CppCstring); // mutató void(string)-re 

void fi(string); // void(string) 

int f2(string); // int(string) 

void f3GCint"); // void(int") 

void JO 

( 
pf- fi; // rendben 
bf- £f2 // hiba: rossz visszatérési típus 
bf- £f3; // hiba: rossz paramétertípus 
Ppf"Héra"); // rendben 
PK DD; // hiba: rossz paramétertípus 
int i — pf("Zeusz"); // hiba: void értékadás int-nek 

j 


A paraméterátadás szabályai a közvetlen függvényhívások és a függvények mutatón keresz- 
tül történő meghívása esetében ugyanazok. Gyakran kényelmes, ha nevet adunk egy függ- 
vényre hivatkozó mutató típusnak, hogy ne mindig a meglehetősen nehezen érthető dek- 
larációformát használjuk. Íme egy példa egy UNIX-os rendszer-fejállományból: 


typedef void CSIG TYP)Gnu; // a Ssignal.h: fejállományból 
typedef void CSIG ARG TYPIGnU; 
SIG TYP signal(int, SIG ARG TYP; 


A függvényekre hivatkozó mutatókból álló tömbök gyakran hasznosak. Például az egeret 
használó szövegszerkesztőm menürendszere az egyes műveleteket jelölő függvényekre hi- 
vatkozó mutatókból összeállított tömbökkel van megvalósítva. Itt nincs lehetőségünk, hogy 
a rendszert részletesen ismertessük, de az alapvető ötlet ez: 


typedef void CPIPO; 


PF edit ops[] -( /7 szerkesztőműveletek 


kcut, kpaste, kg copy, ksearch 


Ü; 


PF file ops[] -(f // fájlkezelés 
kopen, kappend, £close, £ write 
2. 


Jo 


Az egér gombjaival kiválasztott menüpontokhoz kapcsolódó műveleteket vezérlő mutató- 
kat így határozhatjuk meg és tölthetjük fel értékkel: 


PF" button2 - edit ops; 
PF" button3 - file ops; 
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A teljes megvalósításhoz több információra van szükség ahhoz, hogy minden menüelemet 
meghatározhassunk. Például tárolnunk kell valahol azt a karakterláncot, amelyik meghatá- 
rozza a kiírandó szöveget. Ahogy a rendszert használjuk, az egérgombok jelentése gyakran 
megváltozik a környezettel együtt. Az ilyen változásokat (részben) úgy hajtjuk végre, hogy 
módosítjuk a gombokhoz kapcsolt mutatók értékét. Amikor a felhasználó kiválaszt egy me- 
nüpontot (például a 3-as elemet a 2-es gomb számára), a megfelelő művelet hajtódik végre: 


button22]IO; // button2 harmadik függvényének meghívása 


Akkor tudnánk igazán nagyra értékelni a függvényekre hivatkozó mutatók kifejezőerejét, 
ha nélkülük próbálnánk ilyen kódot írni — és még jobban viselkedő rokonaik, a virtuális 
függvények (§12.2.6) nélkül. Egy menüt futási időben úgy módosíthatunk, hogy új függvé- 
nyeket teszünk a művelettáblába, de új menüket is könnyen létrehozhatunk. 


A függvényekre hivatkozó mutatók arra is használhatók, hogy a többalakú (polimorf) eljá- 
rások — azaz amelyeket több, különböző típusú objektumra lehet alkalmazni — egyszerű for- 
máját adják: 


typedef int (CFT)(const void?, const void"); 


void ssort(void" base, size tn, size t sz, CFT cmp) 

/ 
A "base" vektor "n" elemének rendezése növekvő sorrendbe 
a "cmp" által mutatott összehasonlító függvény segítségével. 
Az elemek "sz" méretűek. 


Shell rendezés (Knuth, 3. kötet, S4.o.) 
44 


í 
for (int gap-n/2; OSgap; gap/-2) 
for Gint i-gap; izn; it4) 
for (int j-i-gap; 02-i; j--gap) ( 
char? b - static castáchar"r-(base9; // szükséges típuskényszerítés 


char" pj — baj"sz; // kbaselj] 
char" pig - ba(jrgap)"sz; // k baseljtgapi 
if (cmp(pjg bj) 20) f // baselj] és baselj:gap! felcserélése 


for (int k-0; kesz; kt) f 
char temp — pjlkl; 
Dilk! - piglkl; 
biglk] - temp; 
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Az ssortO nem ismeri azoknak az objektumoknak a típusát, amelyeket rendez, csak az ele- 
mek számát (a tömb méretét), az egyes elemek méretét, és azt a függvényt, melyet meg kell 
hívnia, hogy elvégezze az összehasonlítást. Az ssortO típusát úgy választottuk meg, hogy 
megegyezzen a szabványos C könyvtári gsortO rendező eljárás típusával. A valódi progra- 
mok a gsortO-ot, a Ct4 standard könyvtárának sort algoritmusát (418.7.1), vagy egyedi ren- 
dező eljárást használnak. Ez a kódolási stílus gyakori C-ben, de nem a legelegánsabb mód- 
ja, hogy ezt az algoritmust C----ban írjuk le (lásd §13.3, §13.5.27. 


Egy ilyen rendező függvényt a következőképpen lehetne egy táblázat rendezésére használni: 


struct User f 
char? name; 
char? id; 
int dept; 

;e 


User heads[ ] — ( 


"Ritchie D.M.", "Amr", 11271, 
"Sethi R.", "avi", 11272, 
"Szymanski T.G.", "tgs", 11273, 
"Schryer N.L.", "nis", 11274, 
"Schryer N.L.", "nis", 11275, 
"Kernighan B.W.", "bwk", 11276 


Fej 
void print id(User" v, int n) 


( 
for (int 1-O; izn; í34) 
cout CZ ulil.name cz M! cz ulij.iid cz M" cz ulij.dept cz Mi; 


Először meg kell határoznunk a megfelelő összehasonlító függvényeket, hogy rendezni 
tudjunk. Az összehasonlító függvénynek negatív értéket kell visszaadnia, ha az első para- 
métere kisebb, mint a második, nullát, ha paraméterei egyenlőek, egyéb esetben pedig po- 
zitív számot: 


int cmp1(const void? p, const void?" ag) // nevek (name) összehasonlítása 


( 


return strcmp(static castáconst Usertr(p)-:name,static castáconst User:r(ag)-2name); 


j 


int cmp.X(const void? p, const void?" g) // osztályok (depD) összehasonlítása 


( 
return static castáconst User"r(p)-2dept - static castzconst Usertr(g)-2dept; 


j 
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Ez a program rendez és kíír: 


int mainŐ 
f 
cout cz "Főnökök ábécésorrendben Mn"; 
ssort(heads, 6, sizeof( User), cmp 1); 
brint id(heads, 6); 
cout cz Mt 


cout c£ "Főnökök osztályok szerintm"; 
ssort(heads, 6, sizeof( User), cmp29); 
brint id(heads, 6); 

3 ő 


Egy túlterhelt függvény címét úgy használhatjuk fel, hogy egy függvényre hivatkozó muta- 


tóhoz rendeljük vagy annak kezdőértékül adjuk. Ebben az esetben a cél típusa alapján vá- 
lasztunk a túlterhelt függvények halmazából: 


void fin; 

int (char); 

void CpfUGNnY - kf; // void fin) 

int (pf20(char) - £f; // int ((char) 

void Cpf3)(char) — £f; // hiba: nincs void f((char) 


Egy függvényt egy függvényre hivatkozó mutatón keresztül pontosan a megfelelő paramé- 
ter- és visszatérési típusokkal kell meghívni. Ezen típusokra vonatkozóan nincs automatikus 


konverzió, ha függvényekre hivatkozó mutatókat adunk értékül vagy töltünk fel kezdőérték- 
kel. Ez azt jelenti, hogy 


int cmp3(const mytype", const mytype"?); 


nem megfelelő paraméter az ssortO) számára. Ha cmp3-at elfogadnánk az ssort paramétere- 
ként, megszegnénk azt a vállalást, hogy a cmp3-at mytype" típusú paraméterekkel fogjuk 
meghívni (lásd még §9.2.5-ö0D. 
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7.8. Makrók 


A makrók nagyon fontosak a C-ben, de kevesebb a hasznuk a C-4--ban. Az első makrókra 
vonatkozó szabály: ne használjuk őket, ha nem szükségesek. Majdnem minden makró 
a programozási nyelv, a program, vagy a programozó gyenge pontját mutatja. Mivel átren- 
dezik a programkódot, mielőtt a fordítóprogram látná azt, számos programozási eszköz szá- 
mára komoly problémát jelentenek. Így ha makrót használunk, számíthatunk arra, hogy az 
olyan eszközök, mint a hibakeresők, kereszthivatkozás-vizsgálók és hatékonyságvizsgálók 
gyengébb szolgáltatást fognak nyújtani. Ha makrót kell használnunk, olvassuk el figyelme- 
sen Ct-t-változatunk előfordítójának (preprocessor) hivatkozási kézikönyvét és ne próbál- 
junk túl okosak lenni. Kövessük azt a szokást, hogy a makrókat úgy nevezzük el, hogy sok 
nagybetű legyen bennük. A makrók formai követelményeit az §A.11 mutatja be. 


Egy egyszerű makrót így adhatunk meg: 
Ádefine NAME a sor maradék része 

ahol a NAME szimbólum előfordul, ott kicserélődik a sor maradék részére. Például a 
named - NAME 

kifejezést a következő váltja fel: 
named - a sor maradék része 


Megadhatunk paraméterekkel rendelkező makrót is: 


Ádefine MAC(x,y) argument1: x argument2: y 


Amikor MAC-ot használjuk, paraméterként meg kell adnunk két karakterláncot. Ezek x-et 
és y-t fogják helyettesíteni, amikor MAC behelyettesítődik. Például a 


expanded - MAC(foo bar, yuk yuk) 
így alakul át: 


expanded - argument1: foo bar argument2: yuk yuk 
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A makróneveket nem terhelhetjük túl és a makró-előfordító rekurzív hívásokat sem tud 
kezelni: 


define PRINICa,b) coutzz(ra)cz(b) 
Ádefine PRINT(a,b,c) coutzz(aJcx(DDSK(c) A problémás?: újbóli definíció, nem túlterhelés "/ 


idefine FAC(n) (n:21)?n"FAC(n-1:1 /£ problémás: rekurzív makró "/ 
A makrók karakterláncokat kezelnek, keveset tudnak a C-- nyelvtanáról és semmit sem 
a C4- típusairól, illetve a hatókörök szabályairól. A fordítóprogram csak a makró behelyet- 
tesített formáját látja, így akkor jelzi a makróban lévő esetleges hibát, amikor a makró behe- 


lyettesítődik, és nem akkor, amikor a makrót kifejtjük, ami nagyon homályos hibaüzenetek- 
hez vezet. 


íme néhány lehetséges makró: 


Ádefine CASE break;case 
define FOREVER forG;) 


Néhány teljesen fölösleges makró: 


itdefine PI 3.141593 
idefine BEGIN ( 
ídefine END ) 


És néhány veszélyes makró: 


Ádefine SOUARE(a) a?a 
Ádefine INCR xx (XXI44 


Hogy lássuk, miért veszélyesek, próbáljuk meg behelyettesíteni ezt: 


int xx - O; // globális számláló 

void JO 

f 
int xx — 0; // lokális változó 
int y -— SOUARE(xx1-2); [y7-xxt12txxt2 vagyis y-xxt(2txx)42 
INCR xx; // a lokális xx növelése 


J 
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Ha makrót kell használnunk, használjuk a :: hatókör-jelzőt, amikor globális nevekre (44.9.4) 
hivatkozunk, és a makró paraméterek előfordulásait tegyük zárójelbe, ahol csak lehetséges: 


zdefine MINCa, b) (((a)c(b)):(a):(b)) 


Ha bonyolult makrókat kell írnunk, amelyek megjegyzésekre szorulnak, bölcs dolog /£ §/ 
megjegyzéseket használnunk, mert a C---- eszközök részeként néha C előfordítókat használ- 
nak, ezek viszont nem ismerik a // jelölést: 


$define M2Xa) something(a) /£ értelmes megjegyzés "/ 


Makrók használatával megtervezhetjük saját, egyéni nyelvünket. Ha azonban ezt a , kibőví- 
tett nyelvet" részesítjük előnyben a sima C-r--szal szemben, az a legtöbb C-t programozó 
számára érthetetlen lesz. Továbbá a C előfordító egy nagyon egyszerű makró-feldolgozó. 
Ha valami nem magától értetődőt akarunk csinálni, akkor az vagy lehetetlennek, vagy szük- 
ségtelenül nehéznek bizonyulhat. A const, inline, template, enum és namespace 
megoldásokat arra szánták, hogy a hagyományos előfordított szerkezeteket kiváltsák: 


const int answer — 42; 
templatecxciass T: inline T min(T a, T b) f return (acb)2a:b; ) 


Amikor makrót írunk, nem ritka, hogy egy új névre van szükségünk valami számára. Két ka- 
rakterláncot a $1 makróoperátorral összefűzve például új karakterláncot hozhatunk létre: 


Ádefine NAME2X(a,b) asib 


int NAME2X(hack,cah) O; 


Ez a következőt eredményezi a fordítóprogram számára: 


int hackcahO; 


tundef X 


utasítás biztosítja, hogy X nevű makró nem lesz definiálva — akkor sem, ha az utasítás előtt 
szerepelt ilyen. Ez bizonyos védelmet ad a nem kívánt makrók ellen, de nem tudhatjuk, 
hogy egy kódrészletben mit feltételezzünk X hatásairól. 
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7.8.1. Feltételes fordítás 


A makrók egy bizonyos használatát majdnem lehetetlen elkerülni. Az ifdef azonosító 
direktíva arra utasítja a fordítóprogramot, hogy feltételesen minden bemenetet figyelmen 
kívül hagyjon, amíg az fendif utasítással nem találkozik. Például az 


int (int a 
iifdef arg two 
int b 

fendif 

); 


kódrészletből a fordítóprogram ennyit lát (kivéve ha az arg two nevű makrót a zdefine 
előfordító direktívával korábban definiáltuk): 


int (int a 
J; 


Ez megzavarja azokat az eszközöket, amelyek ésszerű viselkedést tételeznek fel a progra- 
mozóról. 


Az fifdef legtöbb felhasználása kevésbé bizarr, és ha mérséklettel használják, kevés kárt 
okoz. Lásd még §9.3.3-at. 


Az ftifdef-et vezérlő makrók neveit figyelmesen kell megválasztani, hogy ne ütközzenek 
a szokásos azonosítókkal: 


struct Call info f 
Node? arg one; 
Node" arg two; 
Ms 

j; 


Ez az ártatlannak látszó forrásszöveg zavart fog okozni, ha valaki a következőt írja: 


Ádefine arg two x 


Sajnos a szokványos és elkerülhetetlenül beépítendő fejállományok sok veszélyes és szük- 
ségtelen makrót tartalmaznak. 
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7.9. Tanácsok 


[1] Legyünk gyanakvóak a nem const referencia paraméterekkel kapcsolatban; ha 
azt akarjuk, hogy a függvény módosítsa paraméterét, használjunk inkább muta- 
tókat és érték szerinti visszaadást. §5.5. 

[2] Használjunk const referencia paramétereket, ha a lehető legritkábbra kell csök- 
kentenünk a paraméterek másolását. §5.5. 

[3] Használjuk a const-ot széleskörűen, de következesen. §7.2. 

[4] Kerüljük a makrókat. §7.8. 

[5] Kerüljük a nem meghatározott számú paraméterek használatát. §7.6. 

[6] Ne adjunk vissza lokális változókra hivatkozó mutatókat vagy ilyen 
referenciákat. §7.3. 

[7] Akkor használjuk a túlterhelést, ha a függvények elvben ugyanazt a műveletet 
hajtják végre különböző típusokon. §7.4. 

[8] Amikor egészekre vonatkozik a túlterhelés, használjunk függvényeket, hogy 
megszüntessük a többértelműséget. §7.4.3. 

[19] Ha függvényre hivatkozó mutató használatát fontolgatjuk, vizsgáljuk meg, hogy 
egy virtuális függvény (42.5.5) vagy sablon (42.7.2) használata nem jobb megol- 
dás-e. §7.7. 

[10] Ha makrókat kell használnunk, használjunk csúnya neveket, sok nagybetűvel. 
§7.8. 


7.10. Gyakorlatok 


1. C1 Deklaráljuk a következőket: függvény, amelynek egy karakterre hivatkozó 
mutató és egy egészre mutató referencia paramétere van és nem ad vissza érté- 
ket; ilyen függvényre hivatkozó mutató; függvény, amelynek ilyen mutató para- 
métere van; függvény, amely ilyen mutatót ad vissza. Írjuk meg azt a függvényt, 
amelynek egy ilyen mutatójú paramétere van és visszatérési értékként paramé- 
terét adja vissza. Tipp: használjunk typedef-et. 

2. 01) Mit jelent a következő sor? Mire lehet jó? 


typedef int (£rifii) (int, int); 
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. (C1,5) Írjunk egy , Helló, világ! -szerű programot, ami parancssori paraméterként 
vesz egy nevet és kiírja, hogy , Helló, név". Módosítsuk ezt a programot úgy, 
hogy tetszőleges számú név paramétere lehessen és mondjon hellót minden 
egyes névvel. 

. (C1,5) Írjunk olyan programot, amely tetszőleges számú fájlt olvas be, melyek 
nevei parancssori paraméterként vannak megadva, és kiírja azokat egymás után 
a cout-ra. Mivel ez a program összefűzi a paramétereit, hogy megkapja a kime- 
netet, elnevezhetjük cat-nek. 

. (C2) Alakítsunk egy kis C programot C4- programmá. Módosítsuk a fejállomá- 
nyokat úgy, hogy minden meghívott függvény deklarálva legyen és határozzuk 
meg minden paraméter típusát. Ahol lehetséges, cseréljük ki a define utasításo- 
kat enum-ra, const-ra vagy inline-ra. Távolítsuk el az extern deklarációkat a .c 
fájlokból, és ha szükséges, alakítsunk át minden függvényt a C--- függvények 
formai követelményeinek megfelelően. Cseréljük ki a mallocO és freeO híváso- 
kat new-ra, illetve delete-re. Távolítsuk el a szükségtelen konverziókat. 

. G2) Írjuk újra az ssortO-ot (§7.7) egy hatékonyabb rendezési algoritmus felhasz- 
nálásával. Tipp: gsortO. 

. (C2,5) Vegyük a következőt: 


struct Tnode f 
string word; 
int count; 
Tnode" left; 
Tnode" right; 
3; 


írjunk függvényt, amellyel új szavakat tehetünk egy Tnode-okból álló fába. 
írjunk függvényt, amely kiír egy Tnode-okból álló fát. Írjunk olyan függvényt, 
amely egy Tnode-okból álló fát úgy ír ki, hogy a szavak ábécésorrendben van- 
nak. Módosítsuk a 7Tnode-ot, hogy (csak) egy mutatót tároljon, ami egy tetszőle- 
gesen hosszú szóra mutat, amit a szabad tár karaktertömbként tárol, a new 
segítségével. Módosítsuk a függvényeket, hogy a 7node új definicióját 
használják. 

. (2,5) Írjunk függvényt, amely kétdimenziós tömböt invertál. Tipp: §C.7. 

. G2) Írjunk titkosító programot, ami a cin-ről olvas és a kódolt karaktereket kiír- 
ja a cout-ra. Használhatjuk a következő, egyszerű titkosító sémát: c karakter tit- 
kosított formája legyen cAkey/i/, ahol key egy karakterlánc, amely parancssori 
paraméterként adott. A program ciklikus módon használja a key-ben lévő karak- 
tereket, amíg a teljes bemenetet el nem olvasta. Ha nincs megadva key (vagy 

a paraméter null-karakterlánc), a program ne végezzen titkosítást. 
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10.(C3,5) írjunk programot, ami segít megfejteni a §7.10[9]-ben leírt módszerrel tit- 
kosított üzeneteket, anélkül, hogy tudná a kulcsot. Tipp: lásd David Kahn: 7he 
Codebreakers, Macmillan, 1967, New York; 207-213. o. 

. C3) Írjunk egy error nevű függvényt, amely 96s, 96c és 96d kifejezéseket tartal- 
mazó, printf stílusú, formázott karakterláncokat vesz paraméterként és ezen kí- 
vül tetszőleges számú paramétere lehet. Ne használjuk a printfO-et. Nézzük 
meg a §21.8-at, ha nem tudjuk, mit jelent a 905, 90c és 90d. Használjuk 
a ccstdarg:-ot. 

12.11 Hogyan választanánk meg a typedef használatával meghatározott függ- 

vényekre hivatkozó mutatótípusok neveit? 

13. 02) Nézzünk meg néhány programot, hogy elképzelésünk lehessen a mostan- 
ság használatos nevek stílusának változatosságáról. Hogyan használják a nagy- 
betűket? Hogyan használják az aláhúzást? Mikor használnak rövid neveket, mint 
amilyen az i és x? 

14. 1) Mi a hiba ezekben a makrókban? 


1 


sa 


Ádefine PI - 3.141593; 
Ádefine MAX(a,b) a:b?a:b 
itdefine fac(a) (a)"fac((a)-1) 


15.(3) Írjunk makrófeldolgozót, amely egyszerű makrókat definiál és cserél ki 
(ahogy a C előfordító teszi). Olvassunk a cin-ről és írjunk a cout-ra. Először ne 
próbáljunk paraméterekkel rendelkező makrókat kezelni. Tipp: az asztali szá- 
mológép (46.1) tartalmaz egy szimbólumtáblát és egy lexikai elemzőt, amit mó- 
dosíthatunk. 

16. (2) Írjuk meg magunk a printO függvényt a §7.5-ből. 

17. G2) Adjunk hozzá a §6.1 pontban lévő asztali számológéphez olyan függvénye- 
ket, mint az sgrtO, logO, és sinO. Tipp: adjuk meg előre a neveket, a függvé- 
nyeket pedig függvényre hivatkozó mutatókból álló tömbön keresztül hívjuk 
meg. Ne felejtsük el ellenőrizni a függvényhívások paramétereit. 

18. (1) Írjunk olyan faktoriális függvényt, amely nem hívja meg önmagát. Lásd 
még §11.14[61-ot. 

19. (2) Írjunk függvényeket, amelyek egy napot, egy hónapot, és egy évet adnak 
hozzá egy Date-hez, ahogy azt a §6.6[13]-ban leírtuk. Írjunk függvényt, ami 
megadja, hogy egy adott Date a hét melyik napjára esik. Írjunk olyan függvényt, 
ami megadja egy adott Date-re következő első hétfő Date-jét. 


Névterek és kivételek 


,— Ez a 787-es év! 
— I.sz." 
(Monty Python) 


, Nincs olyan általános szabály, ami 
alól ne lenne valamilyen kivétel." 
(Robert Burton) 


Modulok, felületek és kivételek 9 Névterek e using e using namespace s Névütközések fel- 
oldása s Nevek keresése s Névterek összetűzése s Névtér-álnevek "e Névterek és C kód s Ki- 
vételek e ihrow és catch s A kivételek és a programok szerkezete e Tanácsok s Gyakorlatok 


8.1. Modulok és felületek 


Minden valóságos program különálló részekből áll. Még az egyszerű , Helló, világ! prog- 
ram is legalább két részre osztható: a felhasználói kódra, ami a Helló, világ! kiírását kéri, és 
a kiírást végző [/O rendszerre. 
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Vegyük a számológép példáját a §6.1-ből. Láthatjuk, hogy 5 részből áll: 


1. A (szintaktikai) elemzőből (parser), ami a szintaktikai elemzést végzi, 

2. az adatbeviteli függvényből vagy lexikai elemzőből (lexer), ami a karakterekből 
szimbólumokat hoz létre 

3. a (karakterlánc, érték) párokat tároló szimbólumtáblából 

. a mainO vezérlőből 

5. és a hibakezelőből 


A 


Ábrával: 





vezérlő 


Y 


elemző 


Y 


adatbeviteli függvény 




















szimbólumtábla 








hibakezelő 











A fenti ábrában a nyíl jelentése: , felhasználja". Az egyszerűsítés kedvéért nem jelöltem, 
hogy mindegyik rész támaszkodik a hibakezelésre. Az igazat megvallva a számológépet há- 
rom részből állóra terveztem, a vezérlőt és a hibakezelőt a teljesség miatt adtam hozzá. 


Amikor egy modul felhasznál egy másikat, nem szükséges, hogy mindent tudjon a felhasz- 
nált modulról. Ideális esetben a modulok legnagyobb része nem ismert a felhasználó elem 
számára. Következésképpen különbséget teszünk a modul és a modul felülete (interfész) 
között. A szintaktikai elemző például közvetlenül csak az adatbeviteli függvény felületére, 
nem pedig a teljes lexikai elemzőre támaszkodik. Az adatbeviteli függvény csak megvaló- 
sítja a felületében közzétett szolgáltatásokat. Ezt ábrával így mutathatjuk be: 
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vezérlő 
szintaktikai elemző felülete .eg...--.------------ szintaktikai elemző megvalósítása 
lexikai elemző felülete ££--------- 4 lexikai elemző megvalósítása 
szimbólumtábla felülete -£------------- szimbólumtábla megvalósítása 
hibakezelő 











A szaggatott vonalak jelentése: , megvalósítja". Ez tekinthető a program valódi felépítésé- 
nek. Nekünk, programozóknak, az a feladatunk, hogy ezt hű módon adjuk vissza a kód- 
ban. Ha ezt tesszük, a kód egyszerű, hatékony, érthető, és könnyen módosítható lesz, mert 
közvetlenül fogja tükrözni eredeti elképzelésünket. 


világosan kifejezni, a §9.3 pontban pedig azt, hogyan rendezhetjük el úgy a program forrás- 
szövegét, hogy abból előnyünk származzon. A számológép kis program; a , valódi életben" 
nem használnám olyan mértékben a névtereket és a külön fordítást (42.4.1, 99.19, mint itt. 
Most csak azért használjuk ezeket, hogy nagyobb programok esetében is hasznos módsze- 
reket mutassunk be, anélkül, hogy belefulladnánk a kódba. A valódi programokban min- 
den modul, amelyet önálló névtér jelöl, gyakran függvények, osztályok, sablonok stb. szá- 
Zait tartalmazza. 


A nyelvi eszközök bő választékának bemutatásához több lépésben bontom modulokra 
a számológépet. Az igazi programoknál nem valószínű, hogy ezen lépések mindegyikét 
végrehajtanánk. A tapasztalt programozó már az elején kiválaszthat egy , körülbelül megfe- 
lelő" tervet. Ahogy azonban a program az évek során fejlődik, nem ritkák a drasztikus szer- 
kezeti változtatások. 


A hibakezelés mindenütt fontos szerepet tölt be a program szerkezetében. Amikor egy 
programot modulokra bontunk vagy egy programot modulokból hozunk létre, ügyelnünk 
kell arra, hogy a hibakezelés okozta modulok közötti függőségekből minél kevesebb le- 
gyen. A Cs kivételeket nyújt arra a célra, hogy elkülönítsük a hibák észlelését és jelzését 
azok kezelésétől. Ezért miután tárgyaltuk, hogyan ábrázolhatjuk a modulokat névterek- 
ként (48.29), bemutatjuk, hogyan használhatjuk a kivételeket arra, hogy a modularitást to- 
vább javítsuk (48.39. 
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A modularitás fogalma sokkal több módon értelmezhető, mint ahogy ebben és a követke- 
ző fejezetben tesszük. Programjainkat például részekre bonthatjuk párhuzamosan végrehaj- 
tott és egymással kapcsolatot tartó folyamatok segítségével is. Ugyanígy az önálló címterek 
(address spaces) és a címterek közötti információs kapcsolat is olyan fontos témakörök, 
amelyeket itt nem tárgyalunk. Úgy gondolom, a modularitás ezen megközelítései nagyrészt 
egymástól függetlenek és ellentétesek. Érdekes módon minden rendszer könnyen modu- 
lokra bontható. A nehézséget a modulok közötti biztonságos, kényelmes és hatékony kap- 
csolattartás biztosítása jelenti. 


8.2. Névterek 


A névterek (namespace) mindig valamilyen logikai csoportosítást fejeznek ki. Azaz, ha 
egyes deklarációk valamilyen jellemző alapján összetartoznak, akkor ezt a tényt kifejezhet- 


jük úgy is, hogy közös névtérbe helyezzük azokat. A számológép elemzőjének (§6.1.1) dek- 
larációit például a Parser névtérbe tehetjük: 


namespace Parser ( 
double expr(booD; 
double prim(bool geD) ( /? ... "/) 
double term(bool get) f / ... "/) 
double expr(bool get) ( /? ... "/) 


Az exprO függvényt először deklaráljuk és csak később fejtjük ki, hogy megtörjük a §6.1.1- 
ben leírt függőségi kört. 
A számológép bemeneti részét szintén önálló névtérbe helyezhetjük: 


namespace Lexer ( 
enum Token value f 


NAME, NUMBER, END, 
PLUS- 4, MINUS- -- , MUL-"", DIV-/, 
PRINT-". , ASSIGN- IPC, RP-))! 


A 


Token value curr. tok; 
double number value; 
string string value; 


Token value get tokenO ( /? ... "/) 
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A névterek ilyen használata elég nyilvánvalóvá teszi, mit nyújt a lexikai és a szintaktikai 
elemző a felhasználó programelemnek. Ha azonban a függvények forráskódját is a névte- 
rekbe helyeztem volna, a szerkezet zavarossá vált volna. Ha egy valóságos méretű névtér 
deklarációjába beletesszük a függvénytörzseket is, általában több oldalas (képernyős) in- 
formáción kell átrágnunk magunkat, mire megtaláljuk, milyen szolgáltatások vannak felkí- 
nálva, azaz, hogy megtaláljuk a felületet. 


Külön meghatározott felületek helyett olyan eszközöket is biztosíthatunk, amelyek kinye- 
rik a felületet egy modulból, amely a megvalósítást tartalmazza. Ezt nem tekintem jó meg- 
oldásnak. A felületek meghatározása alapvető tervezési tevékenység (ásd §23.4.3.4-et), 
hiszen egy modul a különböző programelemek számára különböző felületeket nyújthat, rá- 
adásul a felületet sokszor már a megvalósítás részleteinek kidolgozása előtt megtervezik. 


íme a Parser egy olyan változata, ahol a felületet (interfész) elkülönítjük a megvalósítástól 
(Gmplementáció): 


namespace Parser f 
double prim(booD; 
double term(booD; 
double expr(booD; 

J 


double Parser::prim(bool gep) f£ / ... "/) 
double Parser::term(bool get) f / ... "/) 
double Parser::expr(bool geD f /? ... "/) 


Vegyük észre, hogy a felület és a lényegi programrész szétválasztásának eredményeként 
most minden függvénynek pontosan egy deklarációja és egy definíciója van. A felhasználó 
programelemek csak a deklarációkat tartalmazó felületet fogják látni. A program megvaló- 
sítását — ebben az esetben a függvénytörzseket -— a felhasználó elem látókörén kívül he- 
lyezzük el. 


Láthattuk, hogy egy tagot megadhatunk a névtér meghatározásán belül, és kifejthetjük ké- 
sőbb, a névtér. neve::tag neve jelölést használva. 


A névtér tagjait a következő jelölés használatával kell bevezetni: 
namespace névtér. név f 


// deklaráció és definíciók 


J 
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A névtérdefiníción kívül új tagot nem adhatunk meg minősítő formában: 


void Parser::logical(booD; // hiba: nincs logical0 a Parser névtérben 


A cél az, hogy könnyen meg lehessen találni minden nevet a névtérdeklarációban, és hogy 
a gépelési, illetve az eltérő típusokból adódó hibákat észrevegyük: 


double Parser::trem(bool; — /7 hiba: nincs tremO a Parser névtérben 
double Parser::prim(int9; // hiba: Parser::primO logikai baraméterű 


A névtér (namespace) egyben hatókör (scope), vagyis nagyon alapvető és viszonylag egy- 
szerű fogalom. Minél nagyobb egy program, annál hasznosabbak a névterek, hogy kifejez- 
zék a program részeinek logikai elkülönítését. A közönséges lokális hatókörök, a globális 
hatókörök és az osztályok maguk is névterek (4C.10.3). Ideális esetben egy program min- 
den eleme valamilyen felismerhető logikai egységhez (modulhoz) tartozik. Ezért — elméle- 
tileg — egy bonyolultabb program minden deklarációját önálló névterekbe kellene helyez- 
ni, melyek neve a programban betöltött logikai szerepet jelzi. A kivétel a mainO, amelynek 
globálisnak kell lennie, hogy a futási idejű környezet felismerje (§8.3.3). 


8.2.1. Minősített nevek 


A névterek külön hatókötrt alkotnak. Az általános hatókör-szabályok természetesen rájuk is 
vonatkoznak, így ha egy nevet előzetesen a névtérben vagy egy körülvevő blokkban ad- 
tunk meg, minden további nehézség nélkül használhatjuk. Másik névtérből származó nevet 
viszont csak akkor használhatunk, ha minősítjük névterének nevével: 


double Parser::term(bool get) // figyeljük meg a Parser:: minősítőt 
( 
double left - prim(geD; // nem kell minősítő 
for Gp 
switch (Lexer::curr. tok) ( // figyeljük meg a Lexer:: minősítőt 
case Lexer::MUL: // figyeljük meg a Lexer:: minősítőt 
left "- prim(true); / nem kell minősítő 
128 
j 
Mos 


A Parser minősítőre itt azért van szükség, hogy kifejezzük, hogy ez a termO az, amelyet 
a Parser-ben bevezettünk, és nem valamilyen más globális függvény. Mivel a termO 
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a Parser tagja, nem kell minősítenie a primO-et. Ha azonban a Lexer minősítőt nem tesszük 
ki, a fordítóprogram a curr. tok változót úgy tekinti, mintha az nem deklarált lenne, mivel 
a Lexer névtér tagjai nem tartoznak a Parser névtér hatókörébe. 


8.2.2. Using deklarációk 


Ha egy név gyakran használatos saját névterén kívül, bosszantó lehet állandóan minősíteni 
névterének nevével. Vegyük a következőt: 


double Parser::prim(bool get) // elemi szimbólumok kezelése 


f 
if (geD) Lexer::get tokenO; 


switch (Lexer::curr. tok) ( 

case Lexer::NUMBER: // lebegőpontos konstans 
Lexer::get tokenO; 
return Lexer::number. value; 

case Lexer::NAME: 


f doublek v - tablelLexer::string valuel; 
if Lexer::get tokenO —- Lexer::ASSIGN) v - expr(true); 
return u; 
) 
case Lexer:: MINUS: // mínusz előjel (egyoberandusú mínusz) 


return -prim(true); 
case Lexer::LP: 


f double e - expr(true); 
if Lexer::curr. tok !- Lexer::RP) return Error::error(") szükséges"); 
Lexer::get tokenO; // !)" lenyelése 
return e; 
) 
case Lexer::END: 
return 1; 
default: 


return Error::error( "elemi szimbólum szükséges"); 


A Lexer minősítés ismételgetése igen fárasztó, de ki lehet küszöbölni egy using deklaráció- 
val, amellyel egy adott helyen kijelentjük, hogy az ebben a hatókörben használt get token 
a Lexer get token-je: 


double Parser::prim(bool get) // elemi szimbólumok kezelése 

( 
using Lexer::get token; // a Lexer get token-jének használata 
using Lexer::curr. tok; // a Lexer curr. tok-jának használata 


using Error::error; // az Error error-jának használata 
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if (geD get tokenO; 


switch (curr. tok) ( 

case Lexer:: NUMBER: // lebegőpontos konstans 
get tokenO; 
return Lexer::number value; 

case Lexer::NAME: 


T/ doublek v - tablelLexer::string valuel; 
if (get token —- Lexer::ASSIGN) v - expr(true); 
return u; 

j 

case Lexer:: MINUS: // mínusz előjel 


return -prim(true); 
case Lexer::LP: 


( double e - expr(true); 
if (curr. tok !- Lexer::RP) return error(") szükséges"); 
get tokenO; // !)" lenyelése 
return e; 

J 

case Lexer::END: 
return 1; 

default: 


return error( "elemi szimbólum szükséges"); 


j 


A using direktíva egy lokális szinonímát vezet be. 


A lokális szinonímákat általában célszerű a lehető legszűkebb hatókörrel használni, hogy 
elkerüljük a tévedéseket. A mi esetünkben azonban az elemző minden függvénye ugyan- 
azokat a neveket használja a többi modulból, így a using deklarációkat elhelyezhetjük 
a Parser névtér meghatározásában is: 


namespace Parser ( 


double prim(booD; 
double term(booD; 
double expr(booD; 
using Lexer::get token; // a Lexer get token-jének használata 
using Lexer::curr. tok; // a Lexer curr. tok-jának használata 


using Error::error; // az Error error-jának használata 
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Így a Parser függvényeit majdnem az eredeti változatukhoz (§6.1.1) hasonlóra egyszerűsít- 
hetjük: 


double Parser::term(bool ge) // szorzás és osztás 


( 
double left - prim(geD; 


for GJ) 
switch (curr. tok) f 
case Lexer:: MUL: 
left "— prim(true); 
break; 
case Lexer::DIV: 
if (double d - prim(true)) f 
left /- d; 
break; 
) 
return error( "osztás 0-val"); 
default: 
return left; 


) 


Azt is megtehetnénk, hogy a lexikai szimbólumok (token, nyelvi egység) neveit a Parser 


névtérbe is bevezetjük. Azért hagyjuk őket minősített alakban, hogy emlékeztessenek, 
a Parser a Lexer-re támaszkodik. 


8.2.3. Using direktívák 

Mit tehetünk, ha célunk az, hogy a Parser függvényeit annyira leegyszerűsítsük, hogy pon- 
tosan olyanok legyenek, mint eredeti változataik? Egy nagy program esetében ésszerűnek 
tűnik, hogy egy előző, kevésbé moduláris változatát névtereket használva alakítsuk át. 


A using direktíva majdnem ugyanúgy teszi elérhetővé egy névtér neveit, mintha azokat 
a névterükön kívül vezettük volna be (48.2.8): 


namespace Parser f 
double prim(booD; 
double term(booD; 
double expr(booD; 


using namespbacelLexer; — // a Lexer összes nevét elérhetővé teszi 
using namespbace Error;  // az Error összes nevét elérhetővé teszi 
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Ez lehetővé teszi számunkra, hogy a Parser függvényeit pontosan úgy írjuk meg, ahogy azt 
eredetileg tettük (46.1.1: 


double Parser::term(bool get) // szorzás és osztás 


double left - prim(geV); 


Jor GJ 
switch (curr. tok) ( // a Lexer-beli curr. tok 
case MUL: // a Lexer-beli MUL 
left "- prim(true); 
break; 
case DIV: // a Lexer-beli DIV 
if (double d - prim(true)) f 
left /7 d; 
break; 
) 
return error( "osztás 0-val"); // az Error-beli error 
default: 
return left; 
) 


A using direktívák a névterekben más névterek beépítésére használhatók (§8.2.8), függvé- 
nyekben jelölésbeli segítségként vehetők biztonságosan igénybe (48.3.3.1)9. A globális using 
direktívák a nyelv régebbi változatairól való átállásra szolgálnak (48.2.9), egyébként jobb, 
ha kerüljük őket. 


8.2.4. Több felület használata 


Világos, hogy a Parser számára létrehozott névtér nem a felület, amit a Parser a felhaszná- 
ló programelem számára nyújt. Inkább olyan deklarációhalmaznak tekinthetjük, ami az 
egyes elemző függvények kényelmes megírásához szükséges. A Parser felülete a felhasz- 
náló elemek számára sokkal egyszerűbb kellene, hogy legyen: 


namespace Parser ( 


double expr(booD; 


j 
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Szerencsére a két névtér-meghatározás együttesen létezhet, így mindkettő felhasználható 
ott, ahol az a legmegfelelőbb. Láthatjuk, hogy a Parser névtér két dolgot nyújt: 


[1] Közös környezetet az elemzőt megvalósító függvények számára 
[2] Külső felületet, amit az elemző a felhasználó programelem rendelkezésére bocsát 


Ennek értelmében a main0O vezérlőkód csak a következőt kell, hogy lássa: 


namespace Parser ( // felhasználói felület 
double expr(booD; 
j 


Bármelyik felületet is találtuk a legjobbnak az elemző függvények közös környezetének áb- 
rázolására, a függvényeknek látniuk kell azt: 








namespace Parser ( // felület a megvalósításhoz 
double prim(booD; 
double term(booD; 
double expr(booD; 
using Lexer::get token; // a Lexer get token-jének használata 
using Lexer::curr. tok; // a Lexer curr. tok-jának használata 
using Error::error; // az Error error-jának használata 
J 
Ábrával: 
Parser" Parser 
Driver Parser megvalósítás 

















A nyilak ,a ... által nyújtott felületen alapul" viszonyokat fejezik ki. 
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A Parser" (Parser prime) a felhasználó programelemek számára nyújtott szűk felület; nem 
C44 azonosító. Szándékosan választottam, hogy jelöljem, ennek a felületnek nincs külön 
neve a programban. A külön nevek hiánya nem okozhat zavart, mert a programozók az 
egyes felületek számára különböző és maguktól értetődő neveket találnak ki, és mert 
a program fizikai elrendezése (ásd §9.3-at) természetesen különböző (fájDneveket ad. 


A programozói felület nagyobb a felhasználóknak nyújtottnál. Ha ez a felület egy valódi 
rendszer valóságos méretű moduljának felülete lenne, sokkal gyakrabban változna, mint 
a felhasználók által látható felület. Fontos, hogy a modulokat használó függvényeket (eb- 
ben az esetben a Parser-t használó mainO-0) elkülönítsük az ilyen módosításoktól. 


A két felület ábrázolására nem kell önálló névtereket használnunk, de ha akarnánk, megte- 
hetnénk. A felületek megtervezése az egyik legalapvetőbb tevékenység, de kétélű fegyver. 
Következésképpen érdemes végiggondolni, valójában mit próbálunk megvalósítani, és 
több megoldást is kipróbálni. 


Az itt bemutatott megoldás az általunk megtekintettek közül a legegyszerűbb és gyakran 
a legjobb. Legfőbb gyengéje, hogy a két felület neve nem különbözik, valamint hogy a for- 
dítóprogram számára nem áll rendelkezésre elegendő információ, hogy ellenőrizze a név- 
tér két definiciójának következetességét. A fordítóprogram azonban rendszerint akkor is 
megpróbálja ellenőrizni az összefüggéseket, ha erre nincs mindig lehetősége, a szerkesztő- 
program pedig észreveszi a legtöbb olyan hibát, amin a fordítóprogram átsiklott. 


Az itt bemutatott megoldást használom a fizikai modularitás (§9.3) tárgyalására is, és ezt aján- 
lom arra az esetre is, amikor nincsenek további logikai megszorítások (lásd még §8.2.7-et). 


8.2.4.1. Felülettervezési módszerek 


A felületek célja az, hogy a lehetséges mértékig csökkentsék a programok különböző részei 
között fennálló függőségeket. A kisebb felület könnyebben érthető rendszerhez vezet, mely- 
nek adatrejtési tulajdonságai jobbak, könnyebben módosítható és gyorsabban lefordítható. 


Amikor a függőségeket nézzük, fontos emlékeznünk arra, hogy a fordítóprogramok és 
a programozók az alábbi egyszerű hozzáállással viszonyulnak hozzájuk: ,ha egy definíció 
az X pontról látható (a hatókörben van), akkor bármi, ami az X pontban van leírva, bármi- 
től függhet, ami abban a definícióban lett meghatározva". Persze a helyzet általában nem 
ennyire rossz, mert a legtöbb definíció a legtöbb kód számára nem bír jelentőséggel. Ko- 
rábbi definícióinkat adottnak véve vegyük a következőt: 
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namespace Parser ( // felület a megvalósításhoz 
VUASOS 
double expr(booD; 
ése 

j 


int mainŐ 


( 
Va 
Parser::expr(false9; 
VVK 

J 


A mainO függvény csak a Parser::exprO függvénytől függ, de időre, gondolkodásra, szá- 
molgatásra stb. van szükség ahhoz, hogy erre rájöjjünk. Következésképpen a valóságos mé- 
retű programok esetében a programozók és a fordítási rendszerek többnyire , biztosra men- 
nek" és feltételezik, hogy ahol előfordulhat függőség, ott elő is fordul, ami teljesen ésszerű 
megközelítés. Célunk ezért az, hogy úgy fejezzük ki programunkat, hogy a lehetséges füg- 
gőségek halmazát a valóban érvényben levő függőségek halmazára szűkítjük. 

Először megpróbáljuk a magától értetődőt: a már meglévő megvalósítási felület segítségé- 
vel az elemző számára felhasználói felületet határozunk meg: 


namespace Parser ( // felület a megvalósításhoz 
esés 
double expr(booD; 
Ms 

j 


namespace Parser. interface ( // felület a felhasználóknak 
using Parser::expr; 


j 


Nyilvánvaló, hogy a Parser. interface-t használó programelemek kizárólag — és csupán köz- 
vetett módon -— a Parser::exprO függvénytől függnek. Mégis, ha egy pillantást vetünk a füg- 
gőségek ábrájára, a következőt látjuk: 
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Parser 
A 
Parser. interface 
Driver Parser megvalósítás 




















Most a Driver (a vezérlő) tűnik sebezhetőnek a Parser felület változásaival szemben, pedig 
azt hittük, jól elszigeteltük tőle. Még a függőség ilyen megjelenése sem kívánatos, így meg- 
szorítjuk a Parser. interface függőségét a Parser-től, úgy, hogy a megvalósítási felületnek 
csak az elemző számára lényeges részét (ezt korábban Parsertnek neveztük) tesszük látha- 
tóvá ott, ahol a Parser. interface-t meghatározzuk: 


namespace Parser ( // felület a felhasználóknak 
double expr(booD; 
j 
namespace Parser. interface f // eltérő nevű felület a felhasználóknak 


using Parser::expr; 


j 


Ábrával: 


Parser" Parser 


Parser. interface 


A 














Driver Parser megvalósítás 




















8. Névterek és kivételek 235 


A Parser és a Parser! egységességét biztosítandó, az egyetlen fordítási egységen dolgozó 
fordítóprogram helyett ismét a fordítási rendszer egészére támaszkodunk. Ez a megoldás 
csak abban különbözik a §8.2.4-ben szereplőtől, hogy kiegészül a Parser. interface név- 
térrel. Ha akarnánk, a Parser. interface-t egy saját exprO függvénnyel konkrétan is ábrázol- 
hatnánk: 


namespace Parser. interface ( 
double expr(booD; 


J 


Most a Parser-nek nem kell a hatókörben lennie, hogy  meghatározhassuk 
a Parser. interface-t. Csak ott kell , láthatónak" lennie, ahol a Parser. interface::exprO függ- 
vényt kifejtjük: 


double Parser. interface::expr(bool ge) 


( 


return Parser::expr(get); 


J 


Az utóbbi változatot ábrával így szemléltethetjük: 


Parser. interface Parser 


A 





Parser. interface 
megvalósítás 














Driver Parser megvalósítás 


A függőségeket ezzel a lehető legkevesebbre csökkentettünk. Mindent kifejtettünk és meg- 
felelően elneveztünk. Mégis, ezt a megoldást a legtöbb esetben túlzónak találhatjuk. 
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8.2.5. A névütközések elkerülése 


A névterek logikai szerkezetek kifejezésére valók. A legegyszerűbb eset, amikor két sze- 
mély által írt kódot kell megkülönböztetnünk. Ez gyakran fontos gyakorlati jelentőséggel 
bír. Ha csak egyetlen globális hatókört használunk, igen nehéz lesz a programot különálló 
részekből létrehozni. Az a probléma merülhet fel, hogy az önállónak feltételezett részek 
mindegyike ugyanazokat a neveket használja, így amikor egyetlen programban egyesítjük 
azokat, a nevek ütközni fognak. Vegyük a következőt: 


// my.h: 
char f char); 
int fin; 
class String €/5 ... "7 ); 


// your.h: 
char (char); 
double (double); 
class String €/§ ... "7 ); 


Ha a fentieket meghatározzuk, egy harmadik személy csak nehezen használhatja egyszer- 
re a my.h-t és a your.h-t is. A kézenfekvő megoldás, hogy mindkét deklarációhalmazt saját, 
külön névtérbe helyezzük: 


namespace My f 
char (char); 
int fin; 
class String €/5 ... "7 ); 


J 


namespace Your 
char (char); 
double (double); 


class String €/§ ... "7 ); 


j 


Most már alkalmazhatjuk a My és a Your deklarációit, ha minősítőket (48.2.1), using dekla- 
rációkat (48.2.2) vagy using direktívákat (48.2.3) használunk. 


8.2.5.1. Névtelen névterek 


Gyakran hasznos deklarációk halmazát névtérbe helyezni, pusztán azért, hogy védekez- 
zünk a lehetséges névütközésekkel szemben. A célunk az, hogy a kód helyileg maradjon 
érvényes, nem pedig az, hogy felületet nyújtsunk a felhasználóknak: 
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finclude "header.h" 
namespace Mine f 
int a; 
void JOT... "7? 
intgO0€/E..."/) 
J 


Mivel nem akarjuk, hogy a Mine név , ismert" legyen az adott környezeten kívül is, nem ér- 
demes olyan felesleges globális nevet kitalálni, amely véletlenül ütközhet valaki más neve- 
ivel. Ilyen esetben a névteret névtelenül hagyhatjuk: 


finclude "header.h" 
namespace [ 

int a; 

void JOT" ..."/) 

intg0€f/F ... "7? 
J 


Világos, hogy kell lennie valamilyen módszernek arra is, hogy kívülről férhessünk hozzá 
egy névtelen névtér (unnamed namespace) tagjaihoz. A névtelen névtérhez tartozik egy rej- 


tett using direktíva is. Az előző deklaráció egyenértékű a következővel: 


namespace $8$5 ( 
int a; 
void JOT... "/) 
intg0€f/F ... "7? 
J 


using namespace $$$; 


Itt $$$ valamilyen név, amely egyedi abban a hatókörben, ahol a névteret meghatároztuk. 
A különböző fordítási egységekben lévő névtelen névterek mindig különbözőek. Ahogy azt 
szerettük volna, nincs mód arra, hogy egy névtelen névtér egy tagját egy másik fordítási 
egységből megnevezhessük. 


8.2.6. Nevek keresése 


Egy Ttípusú paraméterrel rendelkező függvényt általában a 7-vel azonos névtérben szokás 
megadni. Következésképpen ha egy függvényt nem találunk meg használati környezeté- 
ben, akkor paramétereinek névterében fogjuk keresni: 


namespace Chrono f 
class Date f/? ... ?/); 
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bool operator-—(const Datek, const std::stringf ); 


std::string format(const Dateg ); // string ábrázolás 
V/úgoAA 


j 


void (Chrono::Date d, int i) 


( 
std::string s - format(d); // Chrono::formatÓ 
std::string t - format); // hiba: a hatókörben nincs formatÓ 


j 


Ez a keresési szabály — a minősítők használatával ellentétben — sok gépeléstől kíméli meg 
a programozót, és nem is , szennyezi" úgy a névteret, mint a using direktíva (48.2.3). Alkal- 
mazása különösen fontos az operátorok operandusai (411.2.4) és a sablonparaméterek 
(4C.13.8.4) esetében, ahol a minősítők használata nagyon fárasztó lehet. 


Vegyük észre, hogy maga a névtér a hatókörben kell, hogy legyen, a függvényt pedig csak 
akkor találhatjuk meg és használhatjuk fel, ha előbb bevezettük. 


Természetesen egy függvény több névtérből is kaphat paramétereket: 


void (Chrono::Date d, std::String 5) 


( 
if (d — 5) ( 
VB 
j 
else if (d -—— "1914 augusztus 4") f 
Ms 
j 


3 


Az ilyen esetekben a függvényt a fordítóprogram a szokásos módon, a hívás hatókörében, 
illetve az egyes paraméterek névterében (beleértve a paraméterek osztályát és alaposztályát 
is) keresi, és minden talált függvényre elvégzi a túlterhelés feloldását (47.4). Nevezetesen, 
a fordító a d--s hívásnál az oberator-—t az f0-et körülvevő hatókörben, az (-—-t string- 
ekre meghatározó) std névtérben, és a Chrono névtérben keresi. Létezik egy 
std::operator--0), de ennek nincs Date paramétere, ezért a Chrono::operator-—-()-t használ- 
ja, amelynek viszont van. Lásd még §11.2.4-et. 
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Amikor egy osztálytag meghív egy névvel rendelkező függvényt, az osztály és bázisosztá- 
lyának tagjai előnyben részesülnek azokkal a függvényekkel szemben, melyeket a fordító- 
program a paraméterek típusa alapján talált. Az operátoroknál más a helyzet (§11.2.1, 
§11.2.49. 


8.2.7. Névtér-álnevek 


Ha a felhasználók névtereiknek rövid neveket adnak, a különböző névterek nevei köny- 
nyebben ütközhetnek: 


namespace A ( // rövid név, (előbb-utóbb) ütközni fog 
VE 
j 


A::String s1 — "Grieg"; 
A::String s2 - "Nielsen"; 


Valódi kódban viszont általában nem célszerű hosszú névtérneveket használni: 


namespace American Telephone and Telegraph ( // túl hosszú 
ÚT éa 
J 


American Telephone and Telegraph::String s3 - "Grieg"; 
American Telephone and Telegraph::String s4 - "Nielsen"; 


A dilemmát úgy oldhatjuk fel, ha a hosszabb névtérneveknek rövid álneveket (alias) adunk: 


// használjunk névtér-álneveket a nevek rövidítésére: 
namespace ATT - American Telephone and Telegraph; 


ATT::String s3 — "Grieg"; 
ATT::String s4 - "Nielsen"; 


A névtér-álnevek azt is lehetővé teszik a felhasználónak, hogy ,a könyvtárra" hivatkozzon 
és egyetlen deklarációban határozza meg, valójában melyik könyvtárra gondol: 


namespace Lib - Foundation library v2r11; 


Ms. 


Lib::set s; 
Lib::String s5 — "Sibelius"; 
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Ez nagymértékben egyszerűsítheti a könyvtárak másik változatra történő cseréjét. Azáltal, 
hogy közvetlenül Zib-et használunk a Foundation library v2r11 helyett, a Lib álnév érté- 
kének módosításával és a program újrafordításával a ,v3r02" változatra frissíthetjük 
a könyvtárat. Az újrafordítás észre fogja venni a forrásszintű összeférhetetlenségeket. Más- 
részről, a (bármilyen típusú) álnevek túlzott használata zavart is okozhat. 


8.2.8. Névterek összefűzése 


Egy felületet gyakran már létező felületekből akarunk létrehozni: 


namespace His string f 
class String €/ ... 7); 
String operator: (const Stringk , const Stringf£ ); 
String operator: (const Stringk , const char"); 
void fill(char); 
47 etet 


J 


namespace Her. vector ( 
templatexclass T: class Vector f / ... "/ ); 
Maas 


J 


namespace My lib f 
using namespace His string; 
using namespace Her. vector; 
void my fct(Stringé ); 


J/ 


Ennek alapján — a My lib névteret használva — már megírhatjuk a programot: 


void JO 

( 
My lib::String s - "Byron"; // megtalálja a My lib::His string::String nevet 
J/ sé 


J 


using namespace My lib; 


void e(VectorsString:£ vs) 
( 

4 es 

my fet(vs[5D; 

VAN 


j 
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Ha az említett névtérben egy explicit módon minősített név (mint a My lib::String) nem be- 
vezetett, a fordító a nevet a using direktívákban szereplő névterekben (például His string) 
fogja keresni. 


Egy elem valódi névterét csak akkor kell tudnunk, ha valamit megakarunk határozni: 


void My lib::filllchar c) // hiba: a My lib-ben nincs megadva fill0 


( 
B/s 


J 


void His string::filllchar c) // rendben: fill0 szerepel a His string-ben 


( 
MV ösvét 


J 


void My lib::my jfctStringg v) // rendben; a String jelentése My. lib::String, ami 
// His string::String 


( 
sss 


J 


Ideális esetben egy névtér 


1. logikailag összetartozó szolgáltatások halmazát fejezi ki, 
2. nem ad hozzáférést a nem kapcsolódó szolgáltatásokhoz, 
3. és nem ró nagy jelölésbeli terhet a felhasználóra. 


Az itt és a következő részekben bemutatott összefűzési, beépítési módszerek —az finclude- 
dal (49.2.1) együtt — komoly támogatást nyújtanak ehhez. 


8.2.8.1. Kiválasztás 


Alkalmanként előfordul, hogy egy névtérből csak néhány névhez akarunk hozzáférni. Ezt 
meg tudnánk tenni úgy is, hogy olyan névtér-deklarációt írunk, amely csak azokat a neve- 
ket tartalmazza, melyeket szeretnénk. Például megadhatnánk a His string azon változatát, 


amely csak magát a String-et és az összefűző operátort nyújtja: 


namespace His string f( // csak egy része a His string-nek 
class String £/? ... 7); 
String operatort(const Stringét, const Stringé ); 
String operatort(const Stringk, const char"); 


J 
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Ez azonban könnyen zavarossá válhat, hacsak nem mi vagyunk a His string tervezői vagy 
, karbantartói". A His string ,valódi" meghatározásának módosítása ebben a deklarációban 
nem fog tükröződni. Az adott névtérben szereplő szolgáltatások kiválasztását jobban ki le- 
het fejezni using deklarációkkal: 


namespace My string f 
using His string::String; 
using His string::oberatort; // bármelyik His string-beli - használható 


j 


A using deklaráció az adott név minden deklarációját a hatókörbe helyezi, így például 
egyetlen using deklarációval egy túlterhelt függvény összes változatát bevezethetjük. 

Így ha a His string-et úgy módosítják, hogy egy tagfüggvényt vagy az összefűző művelet 
egy túlterhelt változatát adják a Sztring-hez, akkor ez a változtatás automatikusan hozzáfér- 
hető lesz a My string-et használó elemek számára. Fordítva is igaz: ha a His string-ből el- 
távolítunk egy szolgáltatást vagy megváltozatjuk a His string felületét, a fordítóprogram fel 
fogja ismerni a My string minden olyan használatát, amelyre ez hatással van (ásd még 
§15.2.29. 


8.2.8.2. Összefűzés és kiválasztás 


A (using direktívákkal történő) összetűzés és a (using deklarációkkal történő) kiválasztás 
összekapcsolása azt a rugalmasságot eredményezi, amelyre a legtöbb valódi programban 
szükségünk van. Ezek révén úgy adhatunk hozzáférést különféle eszközökhöz, hogy fel- 
oldjuk az egybeépítésükből adódó névütközéseket és többértelműségeket: 


namespace His lib f 
class String €/ ... 77); 
templatexclass T: class Vector f€ /§ ... "/ ); 
1 si 


J 


namespace Her. lib ( 
templatexclass T: class Vector f / ... "/ ); 
class String €/§ ... "7 ); 
VÁLA 


j 


namespace My lib f 
using namespace His lib; // minden a His lib-ből 
using namespace Her. lib; // minden a Her. lib-ből 
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using His lib::String; // az esetleges ütközések feloldása a His lib javára 
using Her. lib:: Vector; // az esetleges ütközések feloldása a Her. lib javára 
templatexclass T- class List £/ ... "7 ); // továbbiak 

2700 


J 


Amikor megvizsgálunk egy névteret, a névtérben lévő, kifejezetten megadott nevek (bele- 
értve a using deklarációkkal megadottakat is) előnyben részesülnek azokkal a nevekkel 
szemben, melyeket más hatókörökből tettünk hozzáférhetővé a using direktívával (lásd 
még §C.10.1-e). Következésképpen a My lib-et használó elemek számára a String és 
Vector nevek ütközését a fordítóprogram a His lib::String és Her. lib:: Vector javára fogja fel- 
oldani. Továbbá a My lib::List lesz használatos alapértelmezés szerint, függetlenül attól, 
hogy szerepel-e Lista His lib vagy Her. lib névtérben. 


Rendszerint jobban szeretem változatlanul hagyni a neveket, amikor új névtérbe teszem 
azokat. Ily módon nem kell ugyanannak az elemnek két különböző nevére emlékeznem. 
Néha azonban új névre van szükség, vagy egyszerűen jó, ha van egy új nevünk: 


namespace Lib2 f 


using namespace His lib; // minden a His lib-ből 
using namespace Her. lib; // minden a Her. lib-ből 
using His lib::String; // az esetleges ütközések feloldása a His lib javára 
using Her. lib:: Vector; // az esetleges ütközések feloldása a Her. lib javára 


typedef Her. lib::String Her. string; // átnevezés 


templatexcilass T- class His vec // "átnevezés" 
: public His lib:: VectorsT2 €/? ... "/); 


templatecciass T- class List f / ... "/ 9; / továbbiak 
M/S 
j 


Az átnevezésre nincs külön nyelvi eljárás. Ehelyett az új elemek meghatározására való álta- 
lános módszerek használatosak. 


8.2.9. Névterek és régi kódok 


Sok millió sor C és C4- kód támaszkodik globális nevekre és létező könyvtárakra. Hogyan 
használhatjuk a névtereket arra, hogy csökkentsük az ilyen kódokban lévő problémákat? 
A már létező kódok újraírása nem mindig járható út. Szerencsére a C könyvtárakat úgy is 
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használhatjuk, mintha azokat egy névtérben deklarálták volna. A C---ban írt könyvtárak 
esetében ez nem így van (49.2.4), másrészről viszont a névtereket úgy tervezték, hogy a le- 
hető legcsekélyebb károkozással be lehessen azokat építeni a régebbi C-t programokba is. 


8.2.9.1. Névterek és a C 


Vegyük a hagyományosan első C programot: 
$include cstdio.h: 


int mainŐ 


( 
brintfC Helló, világNm"); 
2 


J 


Ezt a programot nem lenne jó ötlet széttördelni. Az sem ésszerű, ha a szabványos könyvtá- 
rakat egyedi megoldásoknak tekintjük. Emiatt a névterekre vonatkozó nyelvi szabályokat 
úgy határozták meg, hogy viszonylag könnyedén lehessen egy névterek nélkül megírt 
program szerkezetét névterek használatával világosabban kifejezni. Tulajdonképpen erre 
példa a számológép program (§6.19. Ennek megvalósításához a kulcs a using direktíva. 


A stdio.h C fejállományban lévő szabványos bemeneti/kimeneti szolgáltatások deklarációi 
például egy névtérbe kerültek, a következőképpen: 


// stdio.h: 
namespace sid ( 
LAN 
int printf(const char" ... ); 
Za 


j 


using namespace stid; 


Ez megőrzi a visszirányú kompatibilitást. Azoknak viszont, akik nem akarják, hogy a nevek 
automatikusan hozzáférhetők legyenek, készítettünk egy új fejállományt is, a cstdio-t: 


// cstdio: 


namespace sid ( 
Za 
int printfconst char" ... ); 


Masa 
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A C44 standard könyvtárának azon felhasználói, akik aggódnak a deklarációk másolása mi- 
att, a stdio.h-t természetesen úgy fogják meghatározni, hogy beleveszik a csidio-t: 


// stdio.h: 


sincludeccstdioz 
using namespace std; 


A using direktívákat elsődlegesen a nyelv régebbi változatairól való átállást segítő eszköz- 
öknek tekintem. A legtöbb olyan kódot, amely más névtérben lévő nevekre hivatkozik, 
sokkal világosabban ki lehet fejezni minősítésekkel és using deklarációkkal. 


A névterek és az összeszerkesztés közötti kapcsolatot a §9.2.4 részben tárgyaljuk. 


8.2.9.2. Névterek és túlterhelés 


A túlterhelés (47.4) névtereken keresztül működik. Ez alapvető ahhoz, hogy a már meglé- 
vő könyvtárakat a forráskód lehető legkisebb módosításával fejleszthessük névtereket hasz- 
nálóvá. Például: 


// old A.h: 


void fin); 
Ve 


// old B.h: 


void (char); 
Ja 


// old user.c: 


Ainclude "A.h" 
finclude "B.h" 


void gO 


JÉ. 
t 


f 


JCa); // fO-et hívja B.h-ból 


Ezt a programot anélkül alakíthatjuk névtereket használó változatra, hogy a tényleges 
programkódot megváltoztatnánk: 
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// new A.h: 


namespace A ( 
void fin); 
Mé 

J 


// new B.h: 


namespace B ( 
void (char); 
Mas 

j 


// new user.c: 


finclude "A.h" 
finclude "B.h" 


using namespace A; 
using namespace B; 


void g0 
í 


JCa)  — /fO-et hívja B.h-ból 


Ha teljesen változatlanul akartuk volna hagyni a wser.c-t, a using direktívákat a fejállomá- 
nyokba tettük volna. 


8.2.9.3. A névterek nyitottak 


A névterek nyitottak; azaz számos névtér deklarációjából adhatunk hozzájuk neveket: 


namespace A ( 
int fO; // most fO az A tagja 
J 
namespace A ( 
int g0; // most A két tagja fO és g0 


j 


Ezáltal úgy hozhatunk létre egyetlen névtéren belül lévő nagy programrészeket, ahogy egy 
régebbi könyvtár vagy alkalmazás élt az egyetlen globális névtéren belül. Hogy ezt megte- 
hessük, a névtér-meghatározásokat szét kell osztanunk számos fejállomány és forrásfájl kö- 
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zött. Ahogy azt a számológép példájában (§8.2.4.) mutattuk, a névterek nyitottsága lehető- 
vé teszi számunkra, hogy a különböző programelemeknek különböző felületeket nyújt- 
sunk azáltal, hogy egy adott névtér különböző részeit mutatjuk meg nekik. Ez a nyitottság 
szintén a nyelv régebbi változatairól való átállást segíti. Például a 


// saját fejállomány: 
void fO; // saját függvény 
VES 
áincludesstdio.h: 
int 90; // saját függvény 
VA 


újraírható anélkül, hogy a deklarációk sorrendjét megváltoztatnánk: 
// saját fejállomány: 


namespace Mine ( 
void fO; // saját függvény 
VESS 

, 


iincludecstdio.h: 


namespace Mine ( 
int 90; // saját függvény 
Vo. 


Amikor új kódot írok, jobban szeretek sok kisebb névteret használni (lásd 48.2.8), mint iga- 
zán nagy programrészeket egyetlen névtérbe rakni. Ez azonban gyakran kivitelezhetetlen, 
ha nagyobb programrészeket alakítunk át névtereket használó változatra. 


Amikor egy névtér előzetesen bevezetett tagját kifejtjük, biztonságosabb a Mine:: utasítás- 
formát használni ahelyett, hogy újra megnyitnánk a Minet-t: 


void Mine::ffO // hiba: nincs ffO megadva Mine-ban 


t 
MI ötre 


J 


A fordítóprogram ezt a hibát észreveszi. Mivel azonban egy névtéren belül új függvényeket 
is meghatározhatunk, a fordítóprogram a fentivel azonos jellegű hibát az újra megnyitott 
névterekben már nem érzékeli: 
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namespace Minef // Mine újra megnyitása függvények meghatározásához 
void JfO // hoppá! nincs ffO megadva Mine-ban; ezzel a definícióval adjuk hozzá 
( 


Ms 


Var 


A fordítóprogram nem tudhatja, hogy nem egy új //ÓO függvényt akartunk meghatározni. 
A meghatározásokban szereplő nevek minősítésére használhatunk névtér-álneveket 
(48.2.79), de az adott névtér újbóli megnyitására nem. 


8.3. Kivételek 


Ha egy program különálló modulokból áll — különösen ha ezek külön fejlesztett könyvtá- 
rakból származnak -, a hibakezelést két különálló részre kell szétválasztanunk: 


1. az olyan hibaesemények jelzésére, melyeket nem lehet helyben megszüntetni, 
2. illetve a máshol észlelt hibák kezelésére. 


A könyvtár létrehozója felismerheti a futási idejű hibákat, de általában nem tud mit kezde- 
ni velük. A könyvtárt felhasználó programelem tudhatná, hogyan birkózzon meg a hibák- 
kal, de nem képes észlelni azokat — máskülönben a felhasználó kódjában szerepelnének 
a hibákat kezelő eljárások és nem a könyvtár találná meg azokat. 


A számológép példájában ezt a problémát azzal kerültük ki, hogy a program egészét egy- 
szerre terveztük meg, ezáltal beilleszthettük a hibakezelést a teljes szerkezetbe. Amikor 
azonban a számológép logikai részeit különböző névterekre bontjuk szét, látjuk, hogy min- 
den névtér függ az Error névtértől (48.2.2), az Error-ban lévő hibakezelő pedig arra támasz- 
kodik, hogy minden modul megfelelően viselkedik, miután hiba történt. Tegyük fel, hogy 
nincs lehetőségünk a számológép egészét megtervezni és nem akarjuk, hogy az Error és 
a többi modul között szoros legyen a kapcsolat. Ehelyett tegyük fel, hogy a elemzőt és 
a többi részt úgy írták meg, hogy nem tudták, hogyan szeretné a vezérlő kezelni a hibákat. 
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Bár az errorO nagyon egyszerű volt, magában foglalt egy hibakezelési módszert: 


namespace Error f 
int no of errors; 


double error(const char" 5) 


std::cerr ££ "hiba: " c s cz MM; 
no of errorst4t; 
return 1; 


Az errorÓ függvény egy hibaüzenetet ír ki, olyan alapértelmezett értéket ad, mely lehetővé 
teszi a hívó számára, hogy folytassa a számolást, és egy egyszerű hibaállapotot követ nyo- 
mon. Fontos, hogy a program minden része tudjon az error létezéséről és arról, hogyan 
lehet meghívni, illetve mit várhat tőle. Ez túl sok feltétel lenne egy olyan program esetében, 
amit külön fejlesztett könyvtárakból hoztunk létre. 


A hibajelzés és a hibakezelés szétválasztására szánt C4t-4 eszköz a kivétel. Ebben a részben 
röviden leírjuk a kivételeket, abban a környezetben, ahogy a számológép példájában len- 
nének használatosak. A 14. fejezet áttogóbban tárgyalja a kivételeket és azok használatát. 


8.3.1. Dobás és elkapás" 


A kivételeket (exception) arra találták ki, hogy segítsenek megoldani a hibák jelzését: 


struct Range error ( 

int í; 

Range errorGint ii) f i — ti; ) // konstruktor (§2.5.2, §10.2.3) 
zi 


char to charCGint i) 


í 
if (cnumeric limitszchar2::minŐ 11] numeric limitszchar:::maxOc)  // lásd §22.2 
throw Range error(i); 
return it; 


J 


A to charO függvény vagy az i számértékét adja vissza karakterként, vagy Range error ki- 
vételt vált ki. Az alapgondolat az, hogy ha egy függvény olyan problémát talál, amellyel 
nem képes megbirkózni, kivételt vált ki ( kivételt dob", throw), azt remélve, hogy (közve- 
tett vagy közvetlen) meghívója képes kezelni a problémát. Ha egy függvény képes erre, je- 


250 Alapok 


lezheti, hogy el akarja kapni (catch) azokat a kivételeket, melyek típusa megegyezik 
a probléma jelzésére használt típussal. Ahhoz például, hogy meghívjuk a to charO-t és el- 
kapjuk azt a kivételt, amit esetleg kiválthat, a következőt írhatjuk: 


void g(int íi) 
( 
try ( 
char c — to char); 


VB 


catch (Range error) f 
cerr 22 "hoppá"; 


J 


J 


catch (/..."/)( 
Hava 
7; 


szerkezetet kivételkezelőnek (exception handler) nevezzük. Csak közvetlenül olyan blokk 
után használható, amit a try kulcsszó előz meg, vagy közvetlenül egy másik kivételkezelő 
után. A catch szintén kulcsszó. A zárójelek olyan deklarációt tartalmaznak, amely a függ- 
vényparaméterek deklarációjához hasonló módon használatos. A deklaráció határozza meg 
azon objektum típusát, melyet a kezelő elkaphat. Nem kötelező, de megnevezheti az elka- 
pott objektumot is. Ha például meg akarjuk tudni a kiváltott Range error értékét, akkor 
pontosan úgy adhatunk nevet a catch paraméterének, ahogy a függvényparamétereket ne- 
vezzük meg: 


void h(int í) 
( 
try ( 
char c — to char(; 


Za 


catch (Range error x) f 
cerr ££ "hoppá: to char(" cz xi cz In; 
J 


J 


Ha bármilyen try blokkban szereplő vagy onnan meghívott kód kivételt vált ki, a try blokk 
kezelőit kell megvizsgálni. Ha a kivétel típusa megegyezik a kezelőnek megadott típussal, 
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a kezelő végrehajtja a megfelelő műveletet. Ha nem, a kivételkezelőket figyelmen kívül 
hagyjuk és a try blokk úgy viselkedik, mint egy közönséges blokk. Ha a kivételt nem kap- 
ja el egyetlen try blokk sem, a program befejeződik (§14.7). 


A C44 kivételkezelése alapvetően nem más, mint a vezérlés átadása a hívó függvény meg- 
felelő részének. Ahol szükséges, a hibáról információt adhatunk a hívónak. A C programo- 
zók úgy gondolhatnak a kivételkezelésre, mint egy olyan, ,jól viselkedő" eljárásra, amely 
a setjmp/longjmp (§16.1.2) használatát váltja fel. Az osztályok és a kivételkezelés közötti köl- 
csönhatást a 14. fejezetben tárgyaljuk. 


8.3.2. A kivételek megkülönböztetése 


Egy program futásakor általában számos hiba léphet fel, melyeket különböző nevű kivéte- 
leknek feleltethetünk meg. Én a kivételkezelés céljára külön típusokat szoktam megadni. Ez 
a lehető legkisebbre csökkenti a céljukkal kapcsolatos zavart. Beépített típusokat, mint ami- 
lyen az int, viszont sohasem használok kivételként. Egy nagy programban nem lenne haté- 
kony mód arra, hogy megtaláljam a más célra használt int kivételeket, ezért sosem lehetnék 


biztos abban, hogy az int egy efféle eltérő használata nem okoz-e zavart az én kódomban. 


Számológépünknek (§6.1) kétfajta futási idejű hibát kell kezelnie: a formai követelmények 
megsértését és a nullával való osztás kísérletét. A kezelőnek nem kell értéket átadni abból 
a kódból, amelyik felismerte a nullával való osztás kísérletét, így a nullával való osztást egy 
egyszerű üres típussal ábrázolhatjuk: 


struct Zero. divide ( ?;; 


Másrészt a kezelő a nyelvi hibákról bizonyára szeretne jelzést kapni. Itt egy karakterláncot 
adunk át: 


struct Syntax error ( 
const char? p; 
Syntax errorcconst char" pfp- a) 


); 


A kényelmesebb jelölés végett a szerkezethez hozzáadtam egy konstruktort (42.5.2, 
§10.2.3. 


Az elemzőt használó programrészben megkülönböztethetjük a két kivételt, ha mindkettő- 
jük számára hozzáadunk egy-egy kezelőt a try blokkhoz, így szükség esetén a megfelelő 
kezelőbe léphetünk. Ha az egyik kezelő , alján kiesünk", a végrehajtás a kezelők listájának 
végétől folytatódik: 
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try ( 
Mas 
expr(false); 
// kizárólag akkor jutunk ide, ha exprO nem okozott kivételt 
VS 
j 


catch (Syntax error) f( 
// szintaktikus hiba kezelése 


) 
catch (Zero divide) ( 


// nullával osztás kezelése 


J 


// akkor jutunk ide, ha exprO nem okozott kivételt vagy ha egy Syntax error 
// vagy Zero divide kivételt elkaptunk (és kezelőjük nem tért vissza, 
// nem váltott ki kivételt, és más módon sem változtatta meg a vezérlés0. 


A kezelők listája némileg egy switch utasításhoz hasonlít, de itt nincs szükség break utasí- 
tásokra. E listák formai követelményei részben ezért különböznek a case-étől, részben pe- 
dig azért, hogy jelöljék, minden kezelő külön hatókört (44.9.4) alkot. 

A függvényeknek nem kell az összes lehetséges kivételt elkapniuk. Az előző try blokk pél- 
dául nem próbálta elkapni az elemző bemeneti műveletei által kiváltott kivételeket, azok 
csupán , keresztülmennek" a függvényen, megfelelő kezelővel rendelkező hívót keresve. 


A nyelv szempontjából a kivételeket rögtön kezeltnek tekintjük, amint , belépnek" a keze- 
lőjükbe, ezért a try blokkot meghívó programrésznek kell foglalkoznia azokkal a kivételek- 
kel, melyek a kezelő végrehajtása közben lépnek fel. A következő például nem okoz vég- 
telen ciklust: 


class Input overflow ( /§ ... "/ 3); 


void JO 
( 
yt 
I a6s 
j 
catch (Input overflow) f 
Mag 


throw Input overflowO; 
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A kivételkezelők egymásba is ágyazhatók: 


class XXII£/8 ... 73; 


void JO 


( 
Mé 


try ( 
H//9YA 


; 
catch (XXID (f 


Iry( 
// valami bonyolult 


) 
catch (XXID (f 
// a bonyolult kezelő nem járt sikerrel 


) 
VAS 


Ilyen — gyakran rossz stílusra utaló — egymásba ágyazott kivételkezelőket azonban ritkán 
írunk. 


8.3.3. Kivételek a számológépben 


Az alapvető kivételkezelő eljárásokból kiindulva újraírhatjuk a §6.1 részben szereplő számo- 
lógépet, hogy különválasszuk a futási időben talált hibák kezelését a számológép fő prog- 
ramrészétől. Ez a program olyan elrendezését eredményezi, amely jobban hasonlít a külön- 
álló, lazán kapcsolódó részekből létrehozott programokéra. 


Először kiküszöbölhetjük az errorO függvényt. Helyette az elemző függvények csak a hi- 
bák jelzésére használatos típusokról fognak tudni: 


namespace Error f 
struct Zero. divide ( ?;; 


struct Syntax error ( 
const char? p; 
Syntax errorcconst char" pfp- a) 
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Az elemző három szintaktikus hibát ismer fel: 


Lexer::Token value Lexer::get tokenŐ 


( 
using namespace std; // az input, isalphaO, stb. használata miatt (§6.1.7) 
Ms 
default: // NAME, NAME -, vagy hiba 
if (isalpha(Cch)) f 
inbut-:putback(ch); 
tinput 55 string value; 
return curr. tok-NAME; 
string value - ch; 
while (input-:get(ch) k.k isalnum(ch)) 
string valuepush back(ch); 
inbut-2putback(ch); 
return curr. tok-NAME; 
) 
throw Error::Syntax. error( "rossz szimbólum"); 
) 
J 
double Parser::prim(bool ge) // elemi szimbólumok kezelése 
( 
74 
case Lexer::LP: 
( double e - expr(true); 
if (curr. tok !- Lexer::RP) throw Error::Syntax errorC")" szükséges"); 
get tokenO; // !)" lenyelése 
return e; 
J 
case Lexer::!END: 
return 1; 
default: 


throw Error::Syntax. error( "elemi szimbólum szükséges"); 


j 


j 


Ha az elemző ilyen hibát talál, a tarow-t használja arra, hogy átadja a vezérlést egy kezelő- 
nek, amelyet valamilyen (közvetett vagy közvetlen) hívó függvény határoz meg. A throw 
operátor egy értéket is átad a kezelőnek. Például a 


throw Syntax error( "elemi szimbólum szükséges"); 


a kezelőnek egy Syntax error objektumot ad át, amely a brimary expected karakterláncra 
hivatkozó mutatót tartalmazza. 
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A nullával való osztás hibájának jelzéséhez nem szükséges semmilyen adatot átadni: 


double Parser::term(bool ge) // szorzás és osztás 
( 
VAKESS 
case Lexer::DIV: 
if (double d - prim(true)) f 


left /- d; 
break; 
j 
throw Error::Zero. divideO; 
S 
j 


Most már elkészíthetjük a vezérlőt, hogy az kezelje a Zero divide és Syntax error kivétele- 
ket: 


int main(int argc, char?" argul )) 


f 
FT 
while Cinpun f 
try f 
Lexer::get tokenO; 
if Lexer::curr. tok -- Lexer::"END) break; 
if Lexer::curr. tok -——- Lexer::PRINT) continue; 
cout 22 Parser::expr(false) cz Mi; 
) 
catch(Error::Zero. divide) f 
cerr ££ "nullával osztás kísérletMtn"; 
if Lexer::curr. tok !- Lexer::PRINT) skipO; 
) 
catch(Error::Syntax error e) f 
cerr ££ "formai hiba:" cz ep cz Mn; 
if Lexer::curr. tok !- Lexer::PRINT) skipO; 
) 
) 


if (input !- £cin) delete input; 
return no of errors; 


J 


Ha nem történt hiba a PRINT (azaz sorvége vagy pontosvessző) szimbólummal lezárt kife- 
jezés végén, a mainO meghívja a skipO helyreállító függvényt. A skibO az elemzőt egy 
meghatározott állapotba próbálja állítani, azáltal, hogy eldobja a karaktereket addig, amíg 
sorvégét vagy pontosvesszőt nem talál. A skipO függvény, a no of errors és az input ké- 
zenfekvő választás a Driver névtér számára: 
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namespace Driver f 
int no of errors; 
std::istream" input; 
void skipO; 


j 


void Driver::skipO 
t 


no of errors44; 


while Cinpun f // karakterek elvetése sortörésig vagy pontosvesszóig 
char ch; 
inbut-2get(ch); 


switch (ch) f 
case MI: 
case [ : 

return; 


j 
j 


j 


A skipO kódját szándékosan írtuk az elemző kódjánál alacsonyabb elvonatkoztatási szinten. 
Így az elemzőben lévő kivételek nem kapják el, miközben éppen az elemző kivételeinek 
kezelését végzik. Megtartottam azt az ötletet, hogy megszámoljuk a hibákat, és ez a szám 
lesz a program visszatérési értéke. Gyakran hasznos tudni a hibákról, még akkor is, ha 
a program képes volt helyreállni a hiba után. 


A mainOŐ-t nem tesszük a Driver névtérbe. A globális mainO a program indító függvénye 
(43.29, így a mainŐ egy névtéren belül értelmetlen. Egy valóságos méretű programban 
a mainO kódjának legnagyobb részét a Driver egy külön függvényébe tenném át. 


8.3.3.1. Más hibakezelő módszerek 


Az eredeti hibakezelő kód rövidebb és elegánsabb volt, mint a kivételeket használó válto- 
Zat. Ezt azonban úgy érte el, hogy a program részeit szorosan összekapcsolta. Ez a megkö- 
zelítés nem felel meg olyan programok esetében, melyeket külön fejlesztett könyvtárakból 
hoztak létre. Felvetődhet, hogy a különálló skipO hibakezelő függvényt a mainO-ben, egy 
állapotváltozó bevezetésével küszöböljük ki: 


int main(int argc, char" argul )) // rossz stílus 
( 
Masa 


bool in error - false; 
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while GDriver::inbut) f 


try ( 
Lexer::get tokenO; 
if (Lexer::curr. tok -—- Lexer::"END) break; 
if Lexer::curr. tok -- Lexer::PRINT) f 
in error — false; 
continue; 
) 
if Gn error —- false) cout 2£ Parser::expr(false) cz MM; 
) 


catch(Error::Zero. divide) ( 
cerr ££ "nullával osztás kísérletMtn"; 
4-4 Driver::no of errors; 
in error — true; 
) 
catch(Error::Syntax error e) f 
cerr ££ "formai hiba:" cz ep cz Mn; 
44 Driver::no of errors; 
in error — true; 
) 
) 
if Driver::input !1- éstd::cin) delete Driver::input; 
return Driver::no of errors; 


J 


Ezt számos okból rossz ötletnek tartom: 


1. Az állapotváltozók gyakran zavart okoznak és hibák forrásai lehetnek, külö- 
nösen akkor, ha lehetőséget adunk rá, hogy elszaporodjanak és hatásuk nagy 
programrészekre terjedjen ki. Nevezetesen az in error-t használó mainO-t 
kevésbé olvashatónak tartom, mint a skibO függvényt használó változatot. 

2. Általában jobb külön tartani a hibakezelést és a ,közönséges" kódot. 

3. Veszélyes, ha a hibakezelés elvonatkoztatási szintje megegyezik annak a kód- 
nak az absztrakciós szintjével, ami a hibát okozta; a hibakezelő kód ugyanis 
megismételheti azt a hibát, amely a hibakezelést először kiváltotta. (A gyakorla- 
tok között szerepel, hogy mi történik, ha a mainO in error-t használ. §8.5[7D. 

4. Több munkával jár az egész kódot módosítani a hibakezelés hozzáadásával, 
mint külön hibakezelő függvényeket adni a kódhoz. 


A kivételkezelés nem helyi problémák megoldására való. Ha egy hiba helyben kezelhető, 
akkor majdnem mindig ezt is kell tennünk. Például nincs ok arra, hogy kivételt használjunk 
a ,túl sok paraméter" hiba fellépésekor: 
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int main(int argc, char"? argul)) 
( 

using namespace stid; 

using namespace Driver; 


switch (argc) ( 


case I: // olvasás szabványos bemenetről 
input - Gcin; 
break; 

case 2: // karakterlánc paraméter beolvasása 
inbut - new istringstream(argul1)); 
break; 

default: 
cerr 22 "túl sok paraméter"; 
return 1; 

J 


// mint korábban 
VA 


A kivételek további tárgyalása a 14. fejezetben történik. 


8.4. Tanácsok 


[1] Használjunk névtereket a logikai felépítés kifejezésére. 48.2. 

[2] A mainO kivételével minden nem lokális nevet helyezzünk valamilyen névtér- 
be. §8.2. 

[3] A névtereket úgy tervezzük meg, hogy utána kényelmesen használhassuk, anél- 
kül, hogy véletlenül hozzáférhetnénk más, független névterekhez. §8.2.4. 

I4] Lehetőleg ne adjunk a névtereknek rövid neveket. §8.2.7. 

[5] Ha szükséges, használjunk névtér-álneveket a hosszú névtérnevek rövidítésére. 
48.2.7. 

[6] Lehetőleg ne rójunk nehéz jelölésbeli terheket névtereink felhasználóira. §8.2.2., 
48.2.3. 

[71 Használjuk a Névtér::tag jelölést, amikor a névtér tagjait meghatározzuk. 48.2.8. 

[8] A using namespace-t csak a C-ről vagy régebbi C-4---változatokról való átállás- 
kor, illetve helyi hatókörben használjuk. 48.2.9. 

[19] Használjunk kivételeket arra, hogy a szokásos feldolgozást végző kódrészt elvá- 
lasszuk attól a résztől, amelyben a hibákkal foglalkozunk. 48.3.2. 
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[10] Inkább felhasználói típusokat használjunk kivételekként, mint beépített típuso- 
kat. §8.3.2. 
[11] Ne használjunk kivételeket, amikor a helyi vezérlési szerkezetek is megfelelőek. 


§8.3.3.1. 


8.5. Gyakorlatok 


1. (C2,5) Írjunk string elemeket tartalmazó kétirányú láncolt lista modult a §2.4-ben 
található Szack modul stílusában. Próbáljuk ki úgy, hogy létrehozunk egy prog- 
ramnyelvekből álló listát. Adjunk erre listára egy sortO függvényt és egy olyat, 
ami megfordítja a listában szereplő karakterláncok sorrendjét. 

2. C2) Vegyünk egy nem túl nagy programot, amely legalább egy olyan könyv- 
tárat használ, ami nem használ névtereket. Módosítsuk úgy, hogy a könyvtár 
névtereket használjon. Tipp: 48.2.9. 

3. (2) Készítsünk modult a számológép programból névterek felhasználásával 
a §2.4 pont stílusában. Ne használjunk globális using direktívákat. Jegyezzük fel, 
milyen hibákat vétettünk. Tegyünk javaslatokat arra, miként kerülhetnénk el az 
ilyen hibákat a jövőben. 

4. (1) Írjunk programot, amelyben egy függvény kivételt , dob", egy másik pedig 
elkapja. 

5. (2) Írjunk programot, amely olyan egymást hívó függvényekből áll, ahol a hí- 
vás mélysége 10. Minden függvénynek adjunk egy paramétert, amely eldönti, 
melyik szinten lépett fel a kivétel. A mainO-nel kapjuk el a kivételeket és írjuk 
ki, melyiket kaptuk el. Ne felejtsük el azt az esetet, amikor a kivételt a kiváltó 
függvényben kapjuk el. 

6. (G2) Módosítsuk a §8.5[5] programját úgy, hogy megmérjük, van-e különbség 
a kivételek elkapásának nehézségében attól függően, hogy a szack osztályon 
belül hol jött létre kivétel. Adjunk minden függvényhez egy karakterlánc objek- 
tumot és mérjük meg újra a különbséget. 

7. GC1 Találjuk meg a hibát a §48.3.3.1-ben szereplő mainO első változatában. 

8. (2) Írjunk függvényt, amely vagy visszaad egy értéket, vagy egy paraméter 
alapján eldobja azt. Mérjük meg a két módszer futási idejének különbségét. 

9. (C2) Módosítsuk a §8.5[31-ban lévő számológépet kivételek használatával. 
Jegyezzük fel, milyen hibákat vétettünk. Tegyünk javaslatokat arra, miként 
kerülhetnénk el az ilyen hibákat a jövőben. 

. (C2,5) Írjuk meg a plusO, minusO, multiplyO és divideO függvényeket, amelyek 
ellenőrzik a túlcsordulást és az alulcsordulást, és kivételeket váltanak ki, ha 
ilyen hibák történnek. 

11. C2) Módosítsuk a számológépet, hogy a §8.5[10] függvényeit használja. 
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Forrásfájlok és programok 


, A formának a rendeltetéshez kell igazodnia." 
(Le Corbusier) 


Külön fordítás s Összeszerkesztés s Fejállományok s A standard könyvtár fejállományai e 
Az egyszeri definiálás szabálya 9 Összeszerkesztés nem C-t- kóddal s Az összeszerkesztés 
és a függvényekre hivatkozó mutatók e Fejállományok használata a modularitás kifejezésé- 
re s Egyetlen fejállományos elrendezés s Több fejállományos elrendezés s Állomány- 
őrszemek s Programok s Tanácsok s Gyakorlatok 


9.1. Külön fordítás 


A fájl (az egyes fájlrendszerekben) a tárolás és fordítás hagyományos egysége. Vannak 
olyan rendszerek, amelyek a C-t programokat nem fájlok halmazaként tárolják és fordít- 
ják, és a programok sem fájlok formájában jelennek meg a programozó számára. Ez a leírás 
azonban csak azokra a rendszerekre összpontosít, amelyek a fájlok hagyományos haszná- 
latára támaszkodnak. 
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Egy teljes programot rendszerint lehetetlen egy fájlban tárolni, már csak azért sem, mert 
a szabványos könyvtárak és az operációs rendszer forráskódja általában nem szerepel 
a program forrásában. A valóságos méretű alkalmazásokban az sem kényelmes és célsze- 
rű, ha a felhasználó saját kódját egyetlen fájl tárolja. A program elrendezési módja segíthet 
kihangsúlyozni a program logikai felépítését, segítheti az olvasót a program megértésében 
és segíthet abban is, hogy a fordítóprogram kikényszerítse ezt a logikai szerkezetet. Amikor 
a fordítási egység a fájl, akkor a teljes fájlt újra kell fordítani, ha (bármilyen kis) változtatást 
hajtottak végre rajta, vagy egy másik fájlon, amelytől az előző függ. Az újrafordításra hasz- 
nált idő még egy közepes méretű program esetében is jelentősen csökkenthető, ha a prog- 
ramot megfelelő méretű fájlokra bontjuk. 


A felhasználó a fordítóprogramnak egy forrásjájlt (source file) ad át. Ezután a fájl előfordí- 
tása történik: azaz végrehajtódik a makrófeldolgozás (47.8), az include utasítások pedig 
beépítik a fejállományokat (42.4.1, §9.2.1. Az előfeldolgozás eredményét fordítási egység- 
nek (translation unit) hívják. A fordítóprogram valójában csak ezekkel dolgozik és a Cr 
szabályai is ezek formáját írják le. Ebben a könyvben csak ott teszek különbséget a forrás- 
fájl és a fordítási egység között, ahol meg kell különböztetni azt, amit a programozó lát, és 
amit a fordítóprogram figyelembe vesz. Ahhoz, hogy a programozó lehetővé tegye az elkü- 
lönített fordítást, olyan deklarációkat kell megadnia, amelyek biztosítják mindazt az infor- 
mációt, ami ahhoz szükséges, hogy a fordítási egységet a program többi részétől elkülönít- 
ve lehessen elemezni. A több fordítási egységből álló programok deklarációinak ugyanúgy 
következetesnek kell lenniük, mint az egyetlen forrásfájlból álló programokénak. A rend- 
szerünkben vannak olyan eszközök, amelyek segítenek ezt biztosítani; nevezetesen a szer- 
kesztőprogram (linker) , amely számos következetlenséget képes észrevenni. Ez az a prog- 
ram, ami összekapcsolja a külön fordított részeket. A szerkesztőt néha (zavaró módon) be- 
töltőnek (/oader) is szokták nevezni. A teljes összeszerkesztést el lehet végezni a program 
futása előtt. Emellett lehetőség van arra is, hogy később új kódot adjunk a programhoz (, di- 
namikus szerkesztés"). 


A program fizikai szerkezetén általában a forrásfájlokba szervezett programot értik. A prog- 
ram forrásfájlokra való fizikai szétválasztását a program logikai felépítése kell, hogy irányít- 
sa. A programok forrásfájlokba rendezését is ugyanaz a függőségi kapcsolat vezérli, mint 
azok névterekből való összeállítását. A program logikai és fizikai szerkezetének azonban 
nem kell megegyeznie. Hasznos lehet például több forrásfájlt használni egyetlen névtér 
függvényeinek tárolására, névtér-meghatározások egy gyűjteményét egyetlen fájlban tárol- 
ni, vagy egy névtér definícióit több fájl között szétosztani (48.2.4). 


Először áttekintünk néhány, az összeszerkesztéshez kapcsolódó részletet és szakkifejezést, 
majd kétféle módját ismertetjük annak, hogyan lehet fájlokra szétválasztani a számológépet 


(46.1, 48.29. 
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9.2. Összeszerkesztés 


A függvények, osztályok, sablonok, változók, névterek, felsorolások és felsorolók neveit 
következetesen kell használni az összes fordítási egységben, kivéve, ha kifejezetten lokális- 
ként nem határoztuk meg azokat. 


A programozó feladata biztosítani, hogy minden névtér, osztály, függvény stb. megfelelően 
legyen deklarálva minden olyan fordítási egységben, amelyben szerepel, és hogy minden 
deklaráció, amely ugyanarra az egyedre vonatkozik, egységes legyen. Vegyük például a kö- 
vetkező két fájlt: 


// file1.c: 
int x - 1; 
int fOf/" csinálunk valamit "/ ) 


// file2.c: 
extern int Xx; 
int fO; 
void 90 f x - fO; ) 


A file2.c-ben lévő g0 által használt x és /0 meghatározása a /ileJ1.c-ben szerepel. Az extern 
kulcsszó jelzi, hogy a /file2.c-ben az x deklarációja (csak) deklaráció és nem definíció (44.9). 
Ha x már rendelkezne kezdőértékkel, a fordítóprogram az extern kulcsszót egyszerűen fi- 
gyelmen kívül hagyná, mert a kezdőértéket is meghatározó deklarációk egyben definí- 
ciónak is minősülnek. Egy objektumot a programban csak pontosan egyszer határozhatunk 


meg. Deklarálni többször is lehet, de a típusoknak pontosan meg kell egyezniük: 


// file1.c: 
int x - 1; 
int b — 1; 


extern int c; 


// file2.c: 
int Xx; // jelentése int x — O; 
extern double b; 
extern int c; 


Itt három hiba van: x-et kétszer definiáltuk, b-t kétszer deklaráltuk különböző típusokkal, 
c-t pedig kétszer deklaráltuk, de egyszer sem definiáltuk. Az effajta hibákat (szerkesztési hi- 
ba, linkage error) a fordítóprogram — ami egyszerre csak egy fájlt néz — nem ismeri fel, a 
szerkesztő azonban a legtöbbet igen. Jegyezzük meg, hogy a globális vagy névtér-hatókör- 
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ben kezdőérték nélkül megadott változók alapértelmezés szerint kapnak kezdőértéket. Ez 
nem vonatkozik a lokális változókra (44.9.5, §10.4.2) vagy a szabad tárban létrehozott ob- 
jektumokra (46.2.6). 


A következő programrészlet két hibát tartalmaz: 


// file1.c: 
int X; 
int JO ( return Xx; ) 


// file2.c: 
int X; 


int g0 ( return fO; ) 


A file2.c-ben az f0 meghívása hiba, mert f0-et a file2.c nem deklarálja. Ezenkívül a szer- 
kesztő nem fogja összeszerkeszteni a programot, mert x-et kétszer definiáltuk. Jegyezzük 
meg, hogy az /Ö meghívása a C nyelvben nem lenne hiba (4B.2.29. 


Az olyan neveket, amelyeket a nevet meghatározó fordítási egységtől különböző fordítási 
egységben is használhatunk, ktilső szerkesztésűnek (external linkage) nevezzük. Az előző 
példákban szereplő összes név külső név. Az olyan neveket, amelyekre csak abban a for- 
dítási egységben lehet hivatkozni, ahol meghatározásuk szerepel, belső szerkesztésű név- 


nek nevezzük. 


A helyben kifejtett (inline) függvényeket (§7.1.1, §10.2.9) minden olyan fordítási egységben 
definiálni kell — azonos módon (49.2.3) -—, amelyben használatosak. Ezért a következő pél- 
da nem csak rossz stílusra vall, hanem szabálytalan is: 


// file1.c: 


inline int (int i) f return í; ) 


// file2.c: 


inline int (int i) f return it 1; ) 


Sajnos, ezt a hibát a Ct- egyes változatai nehezen veszik észre, ezért a helyben kifejtett kód 
és a külső szerkesztés következő — különben teljesen logikus — párosítása tiltott, hogy a for- 
dítóprogram-írók élete könnyebb legyen: 


// file1.c: 
extern inline int g(int i); 
int hGnt i) f return 9(; ) // hiba: g0 nincs definiálva ebben a fordítási egységben 


// file2.c: 


extern inline int g(int i) ( return i- 1; ) 
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Alapértelmezés szerint a const-ok (§5.4) és a typedef-ek (44.9.7) belső szerkesztésűek. Kö- 
vetkezésképpen ez a példa szabályos (bár zavaró lehe: 


// file1.c: 
typedef int T; 
const int X — 7; 


// file2.c: 
typedef void T; 
constintx - 8; 


Az olyan globális változók, amelyek egy adott fordítási egységben lokálisnak számítanak, 
gyakran okoznak zavart, ezért legjobb elkerülni őket. A globális konstansokat és a helyben 
kifejtett függvényeket rendszerint csak fejállományokba (49.2.1) szabadna tennünk, hogy 
biztosítsuk a következetességet. A konstansokat kifejezett utasítással tehetjük külső szer- 
kesztésűvé: 


// file1.c: 


extern const int a — 77; 


// file2.c: 


extern const int a; 


void g0 


S 
t 


) 


cout c a cz MM; 


Itt 90 77-et fog kiírni. 


A névtelen névtereket (48.2.5) arra használhatjuk, hogy a neveket egy adott fordítási egység- 
re nézve lokálissá tegyük. A névtelen névterek és a belső szerkesztés hatása nagyon hasonló: 


// file 1.c: 
namespace (í 
class X£/5... 79 
void JO; 
int í; 
8 
, 


// file2.c: 
class X£/5.../93 
void JO; 
int í; 


sza 
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A file1.c-ben lévő f0 függvény nem azonos a file2.c-ben lévő /0 függvénnyel. Ha van egy 
adott fordítási egységre nézve lokális nevünk és ugyanazt a nevet használjuk máshol egy 


külső szerkesztésű egyed számára is, akkor magunk keressük a bajt. 

A C nyelvű és a régebbi C--t programokban a szatic kulcsszót használták (zavaróan) annak 
a kifejezésére, hogy , használj belső szerkesztést" (§B.2.3). A static kulcsszót lehetőleg csak 
függvényeken (47.2.1) és osztályokon (§10.2.4) belül használjuk. 


9.2.1. Fejállományok 


A típusoknak ugyanannak az objektumnak, függvénynek, osztálynak stb. minden deklará- 
ciójában egységesnek kell lenniük, következésképpen a fordítónak átadott és később 
összeszerkesztett forráskódnak is. A különböző fordítási egységekben lévő deklarációk 
egységességének elérésére nem tökéletes, de egyszerű módszer, hogy a végrehajtható kó- 
dot és/vagy adatleírásokat tartalmazó forrásfájlokba beépítjük (Ainclude) a felületre vonat- 
kozó információkat tartalmazó fejállományokat (header). 


Az finclude szövegkezelő eszköz, ami arra való, hogy a forráskód-részeket egyetlen egy- 
ségbe (fájlba) gyűjtsük össze a fordításhoz. Az 


tinclude "beépítendő" 


utasítás a beépítendő fájl tartalmára cseréli azt a sort, amelyben az include előfordul. A fájl 
tartalmának C-t forrásszövegnek kell lennie, mert a fordítóprogram ennek olvasásával ha- 
lad tovább. 


A standard könyvtárbeli fejállományok beépítéséhez a fájl nevét idézőjelek helyett a c 5 
zárójelpárok közé kell foglalni: 


tinclude ciostream: // a szabványos include könyvtárból 
include "myheader.h" // az aktuális könyvtárból 


Sajnos a beépítő utasításban a szóközök mind a £ 5, mind a " " belsejében fontosak: 


$include £ iostream : // nem fogja megtalálni az ciostream:-et 


Furcsának tűnhet, hogy egy fájlt minden egyes alkalommal újra kell fordítani, ha valahová 
máshová beépítjük, de a beépített fájlok jellemzően csak deklarációkat tartalmaznak, és 
nem olyan kódot, amelyet a fordítóprogramnak alaposan elemeznie kellene. Továbbá a leg- 
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több modern C---változat valamilyen formában támogatja az előfordított fejállományokat, 


hogy csökkentse a munkát, amit ugyanannak a fejállománynak az ismételt fordítása jelent. 


Alapszabályként fogadjuk el, hogy egy fejállományban a következők szerepelhetnek: 





Nevesített névterek 
Típusdefiníciók 
Sablondeklarációk 
Sablondefiníciók 
Függvénydeklarációk 
Helyben kifejtett függvények 
definíciói 

Adatdeklarációk 
Konstansdefiníciók 
Felsorolások 
Névdeklarációk 

Beépítő utasítások 
Makródefiníciók 

Feltételes fordítási utasítások 
Megjegyzések 





namespace N€/? ... "/) 

struct Point f int x, y; ); 
templatexciass T- class Z; 
templatexciass T: class Vf /£ ... "/); 
extern int strlen(const char"); 


inline char get(char? p) f return "pr; ? 
extern int a; 

const float pi - 3.141593; 

enum Light f red, yellow, green ); 

class Matrix; 

finclude Zalgorithm: 

define VERSION 12 

íifdef  cblusplus 

/£ check for end of file "/ 





Mindez nem nyelvi követelmény, csak ésszerű módja az sinclude használatának a logikai szer- 


kezet kifejezésére. Ezzel ellentétben egy fejállomány sohasem tartalmazhatja a következőket: 





Közönséges 
függvénydefiníciók 
Adatdefiníciók 
Agregátum-definíciók 
Névtelen névterek 
Exportált 
sablondefiníciók 





char get(char "p) f return "pt; ) 
int a; 

shorttbi[]-f 1, 2, 3 2); 
namespace £ / ... §/) 


export templatexclass TEXRTw9€/5 ... "/) 








A fejállományok hagyomány szerint ./A kiterjesztésűek, a függvény- és adatdefiníciókat tar- 


talmazó fájlok kiterjesztése pedig .c, ezért gyakran hívják ezeket ,.h fájlok"-nak és ,.c fáj- 


lok"-nak. Más szokásos jelöléseket is találhatunk, mint a .C, .cxx, .cbp és .cc. Fordítóprog- 
ramunk dokumentációja ezt jól meghatározza. 
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Az egyszerű állandókat ajánlatos fejállományokba tenni. Az agregátumokat azonban nem, 
mert az egyes C4t-4-változatok nehezen tudják elkerülni, hogy a több fordítási egységben 
előforduló egyedeiből másodpéldányt készítsenek. Ezenkívül az egyszerű esetek sokkal 
gyakoribbak, ezért jó kód készítéséhez fontosabbak. Bölcs dolog nem túl okosnak lenni az 
$include használatánál. Azt ajánlom, csak teljes deklarációkat és definíciókat építsünk be 
és csak globális hatókörben, szerkesztési blokkokban, vagy olyan névtérdefinícióknál, ami- 
kor régi kódot alakítunk át (49.2.2) tegyük ezt. Célszerű elkerülni a makrókkal való ügyes- 
kedést is. Az egyik legkevésbé kedvelt foglalatosságom olyan hibát nyomon követni, amit 
egy olyan név okoz, amelyet egy közvetetten beépített, számomra teljesen ismeretlen fejál- 
lományban szereplő makró helyettesít. 


9.2.2. A standard könyvtár fejállományai 


A standard könyvtár eszközeit szabványos fejállományok halmazán keresztül mutatjuk be 
(416.1.2). A standard könyvtárbeli fejállományokat nem kell utótaggal ellátnunk; tudjuk ró- 
luk, hogy fejállományok, mert beillesztésükhöz az $include £...: formát használjuk az 
$include "..." helyett. A .A kiterjesztés hiánya nem utal semmire a fejállomány tárolásával 
kapcsolatban. Egy olyan fejállomány, mint a cmap:, valószínűleg a map.h nevű szövegfájl- 
ban tárolódik a szokásos könyvtárban. Másfelől a szabványos fejállományokat nem muszáj 
hagyományos módon tárolni. Az egyes C---változatok számára megengedett, hogy kihasz- 
nálják a standard könyvtár definícióinak ismeretét és ezáltal optimalizálják annak megvaló- 
sítását, illetve a szabványos fejállományok kezelésének módját. A nyelv adott megvalósítá- 
sa ismerheti a beépített szabványos matematikai könyvtárat (422.3) és úgy kezelheti az 
tinclude £cmath? utasítást, mint egy kapcsolót, ami anélkül teszi elérhetővé a szabványos 
matematikai függvényeket, hogy bármilyen fájlt beolvasnánk. A C standard könyvtárának 
minden cX.h: fejállományához létezik megfelelő szabványos ccX: Cr-4 fejállomány. 
Az $include ccstdio: például azt nyújtja, amit az include cstdio.h:. A stdio.h fájl általában 
valahogy így néz ki: 


fifdef  cplusplus // csak C44 fordítók számára (f9.2.4) 
namespace sid ( // a standard könyvtárat az std névtér írja le (§8.2.9) 
extern "C" ( // az stdio függvények C szerkesztésűek (§9.2.4) 
endif 

1 eső 

int printfconst char" ...); 

/ 


tifdef  cplusplus 
2 


B b 


J 


using namespace sid; // az stdio elérhetővé tétele a globális névtérben 
endif 
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Azaz a deklarációk (nagy valószínűséggel) közösek, de az összeszerkesztéssel és névterek- 
kel kapcsolatos dolgokra oda kell figyelnünk, hogy lehetővé tegyük, hogy a C és C-t osz- 
tozzanak a fejállományon. 


9.2.3. Az egyszeri definiálás szabálya 


Egy adott osztályt, felsorolást, sablont stb. mindig csak egyszer definiálhatunk egy program- 
ban. Gyakorlati szempontból ez azt jelenti, hogy például egy osztálynak, amelyet valahol 
egy fájlban tárolunk, pontosan egy kifejtéssel kell rendelkeznie. Sajnos, a nyelvi szabály nem 
lehet ennyire egyszerű. Egy osztály definícióját például össze lehet állítani makrók behelyet- 
tesítésével is, de include utasításokkal (49.2.1) szöveges formában két forrásfájlban is el 
lehet helyezni. Még ennél is nagyobb baj, hogy a , fájl" fogalma nem része a C és C-t nyelv- 
nek, így vannak olyan változatok, amelyek a programokat nem forrásfájlokban tárolják. 
Következésképpen a szabványban lévő szabályt — amely azt mondja, hogy egy osztály, sab- 
lon stb. definíciójának egyedinek kell lennie — valamelyest bonyolultabb és ravaszabb mó- 
don fogalmaztuk meg. Ezt a szabályt gyakran az , egyszeri definiálás szabályának" (ODR, 
one-definition rule) nevezik. Azaz egy osztály, sablon, vagy helyben kifejtett függvény két- 
féle definiálása kizárólag akkor fogadható el ugyanazon egyed két példányaként, ha 


1. különböző fordítási egységben szerepelnek és 
2. szimbólumról szimbólumra megegyeznek és 
3. ezen szimbólumok jelentése mindkét fordítási egységben ugyanaz. 


Például: 


// file1.c: 
struct S ( int a; char b; ); 
void (S; 


// file2.c: 
struct S ( int a; char b; ); 
void KS" p)€f/ ..."/) 


Az ODR értelmében a fenti példa helyes és S ugyanarra az osztályra vonatkozik mindkét 
forrásfájlban. Nem bölcs dolog azonban egy definíciót ilyen módon kétszer leírni. Ha vala- 
ki módosítja a /ile2.c-t, azt feltételezheti, hogy az ott szereplő S az S egyetlen definiálása és 
szabadon megváltoztathatja azt, ami nehezen felfedezhető hibát okozhat. 
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Az ODR szándéka az, hogy megengedje egy osztálydefiníció beillesztését különböző for- 
rásfájlokba egy közös forrásfájlból: 


// file s.h: 
struct S f int a; char b; ); 
void (5); 


// file1.c: 
finclude "s.h" 
/fO használata itt 
// file2.c: 
finclude "s.h" 


void (St p)€/E ..."/) 


Ábrával: 


s.h: 





struct S fint a; char D?; 
void KS"; 


















file1.c: file2.c: 








finclude "s.h" include "s.h" 


// fO használata itt void f(S7p) €/..."/2 














Nézzünk példákat az ODR szabály megsértésének mindhárom módjára: 


// file1.c: 
struct S1 ( int a; char b; ) ; 


struct S1 f int a; char b; ); // hiba: két definíció 
Ez azért hiba, mert egy struct-ot egyetlen fordítási egységben nem lehet kétszer definiálni. 


// file1.c: 
struct 52 ( int a; char b; ); 


// file2.c: 
struct 52 (f int a; char bb; );// hiba 
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Ez azért hiba, mert S2 olyan osztályokat nevez meg, amelyek egy tag nevében különböznek. 


// file1.c: 
typedef int X; 
struct 53 ( X a; char b; J; 


// file2.c: 
typedef char X; 
struct 531 X a; char b; ]; — / hiba 


Itt az 53 két definiciója szimbólumról szimbólumra megegyezik, de a példa hibás, mert az 
X név (trükkös módon) mást jelent a két fájlban. 


A legtöbb C---változat nem képes a különböző fordítási egységekben lévő osztály- 
definíciók következetességét ellenőrizni, ezért az ODR-t megsértő deklarációk nehezen 
észrevehető hibákat okozhatnak. Sajnos az a módszer sem képes az ODR utolsóként bemu- 
tatott megszegése ellen védelmet nyújtani, amikor a közös definiciókat fejállományokba 
tesszük és aztán azokat építjük be. A helyi tybedef-ek és makrók ugyanis módosíthatják 
a beépített deklarációk jelentését: 


// file s.h: 
struct S ( Point a; char b; ?); 


// file1.c: 
define Point int 
tinclude "s.h" 


148 


// file2.c: 
class Point f€/E ... ?/ 3; 
finclude "s.h" 


Mz 


Az ilyen kódmódosulás ellen úgy védekezhetünk a legjobban, ha a fejállományokat annyi- 
ra különállóvá tesszük, amennyire csak lehetséges. Például ha a Point osztályt az s.A állo- 
mányban vezettük volna be, a fordítóprogram felismerte volna a hibát. 


A sablondefiníciókat több fordítási egységbe is beépíthetjük, amíg ez nem sérti az ODR-t, 
az exportált sablonokat pedig úgy is használhatjuk, hogy csak a deklarációjukat adjuk meg: 


// file1.c: 
export templatexcilass T- T twice(T 2) ( return tát; ) 
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// file2.c: 
templatexclass T: T twice(T 0); // deklaráció 
int g(int i) f return twice(i); ) 


Az export kulcsszó azt jelenti, hogy , más fordítási egységből elérhető" (413.79. 


9.2.4. Összeszerkesztés nem C-t -k kóddal 


A C4- programok általában más nyelven megírt részleteket is tartalmaznak. Hasonlóan gya- 
kori az is, hogy C4t4 kódrészletet használnak más nyelven megírt programok részeként. 
Az együttműködés a különböző nyelven megírt programrészek között nem mindig 
könnyű - sőt még az azonos nyelven írt, de különböző fordítóprogrammal lefordított kód- 
részletek között sem. A különböző nyelvek és ugyanazon nyelv különböző megvalósításai 
például különbözőképpen használhatják a gépi regisztereket a paraméterek tárolására, 
másképpen helyezhetik azokat a verembe, különböző lehet a beépített típusok, például 
a karakterláncok és egészek szerkezete, illetve azon nevek formája, melyeket a fordítóprog- 
ram a szerkesztőnek átad, és a szerkesztőtől megkövetelt típusellenőrzések. Hogy segít- 
sünk, összeszerkesztési szabályt határozhatunk meg az extern deklarációkra. A következő 
példa bevezeti a C és a Ct- standard könyvtáraiban levő strcpyO függvényt, és meghatá- 
rozza, hogy a C összeszerkesztési szabályainak megfelelően kell azt hozzászerkeszteni 
a kódhoz: 


extern "C" char" strepy(char?, const char? ); 


A deklaráció hatása a , sima" deklarációkétól csak az strcpyO hívására használt összeszer- 
kesztési szabályban tér el. 


extern char" strcpy(char?", const char"); 


Az extern "C" utasítás különösen fontos a C és a C4- közötti szoros kapcsolat miatt. Jegyez- 
zük meg, hogy az extern "C"-ben szereplő "C" az összeszerkesztési szabályt, nem pedig 
a programnyelvet jelöli. Az extern "C"-t gyakran használják olyan Fortran vagy assembler 
eljárásokkal való összeszerkesztéshez, melyek véletlenül éppen megfelelnek a C követel- 
ményeinek. 


Az extern "C" utasítás (csak) az összeszerkesztési szabályt határozza meg, a függvényhí- 
vások szerepét nem befolyásolja. Az extern "C"-ként megadott függvényekre is a C-t tí- 
pusellenőrzési és paraméter-átalakítási szabályai vonatkoznak, nem pedig a gyengébb C 
szabályok. 
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Például: 
extern "C" int fO; 


int g0 
( 


return KV; // hiba: nem vár paramétert 


J 


Kényelmetlen lehet, ha sok deklarációhoz kell hozzáadnunk az extern "C"-t, ezért bevezet- 
tünk egy eljárást, mellyel deklarációk egy csoportjának összeszerkesztését határozhatjuk 
meg: 


extern "C" ( 
char"? strcpy(char", const char"); 
int stremp(const char", const char"); 
int strlenCcconst char? ); 
Mesa 
j 


Ezt a szerkezetet, melyet gyakran szerkesztési blokknak (inkage block) neveznek, úgy is 
használhatjuk, hogy belefoglalunk egy teljes C fejállományt és így alkalmassá tesszük azt 
a C44-ban való használatra: 


extern "C" ( 
finclude Sstring.h: 


J 


A fenti módszer gyakran használatos arra, hogy C fejállományokból C--- fejállományokat 
hozzanak létre. Egy másik lehetőség, ha feltételes fordítást (47.8.1) használunk, hogy közös 
C és C4t4 fejállományt készítsünk: 


fijdef . cblusplus 
extern "C" ( 
fendif 


char"? strcpy(char", const char"); 
int stremp(const char", const char"); 
int strlenCcconst char? ); 
VAN 
áijdef . cblusplus 


fendif 
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A ,készenkapott" " cplusplus makró használatával azt biztosíthatjuk, hogy a C4-4 szerkeze- 
tek eltűnjenek, amikor a fájlt C fejállományként használjuk. 


Egy szerkesztési blokkon belül bármilyen deklaráció szerepelhet: 


extern "C" ( // bármilyen deklaráció jöhet ide, pl: 
int g1; // definíció 
extern int 92; // deklaráció, nem definíció 


j 


Ez a változók hatókörét és tárolási osztályát nem érinti, így g7 globális változó marad, és 
definiciója is lesz, nem csak deklarációja. Ha egy változót csak deklarálni, nem pedig 
definiálni akarunk, az extern kulcsszót közvetlenül a deklaráció előtt kell megadnunk: 


extern "C"intg3; — // deklaráció, nem definíció 


Ez első látásra furcsának tűnik, pedig célja csak annyi, hogy a deklaráció jelentése változat- 
lan maradjon, amikor egy extern deklarációhoz "C"-t adunk Cés a fájl jelentése is, amikor 
majd a szerkesztési blokkba foglaljuk). 

Egy C szerkesztésű nevet névtérben is megadhatunk. A névtér azt befolyásolni fogja, ho- 
gyan lehet a névhez hozzáférni C-- programokból, de azt nem, hogy a szerkesztő hogyan 
fogja látni a nevet. Egy jellemző példa erre az szd névtér printfO függvénye: 


tincludezcstdio:z 
void JO 
( 
std::printf "Helló, "); // rendben 
printfvilágNm"; // hiba: nincs globális printfO 


7 


Még ha std::printfŐO-nek nevezzük is, ez még mindig ugyanaz a régi C printfO (§21.8). Ez 
lehetővé teszi számunkra, hogy C szerkesztésű könyvtárakat építsünk be egy általunk vá- 
lasztott névtérbe, ahelyett, hogy a globális névteret , szennyeznénk". Sajnos ugyanez a ru- 
galmasság nem áll rendelkezésünkre az olyan fejállományok esetében, amelyek C-- szer- 
kesztésű függvényeket határoznak meg a globális névtérben. Ennek az az oka, hogy a Ct- 
egyedek összeszerkesztésénél figyelembe kell venni a névtereket is, így a létrehozott tárgy- 


kód (object fájl) tükrözni fogja a névterek használatát vagy annak hiányát. 


9. Forrásfájlok és programok 275 


9.2.5. Az összeszerkesztés és a függvényekre hivatkozó mutatók 


Ha egy programban a C és C-4- kódrészleteket keverjük, előfordulhat, hogy az egyik nyelven 
megírt függvényekre hivatkozó mutatókat a másik nyelven definiált függvényeknek szeret- 
nénk átadni. Ha a két nyelv adott változatainak összeszerkesztési szabályai, illetve a függ- 
vényhívási eljárások közösek, a függvényekre hivatkozó mutatók átadása egyszerű. Ennyi kö- 
zös tulajdonság azonban általában nem tételezhető fel, így figyelnünk kell arra, hogy biztosít- 
suk a függvények oly módon történő meghívását, ahogy azt a függvény elvárja. Ha egy dek- 
laráció számára meghatározzuk az összeszerkesztési módot, akkor az minden olyan függ- 
vénytípusra, függvénynévre, és változónévre vonatkozni fog, amit a deklarációck) 
bevezet(nek). Ez mindenféle furcsa — de néha alapvető — összeszerkesztési módot lehető- 
vé tesz. Például: 


typedef int ("FTX(const void", const void"); // FT Cxa4 szerkesztésű 


extern "C" ( 


typedef int (tCFT)(const void?t, const void"); // CFT C szerkesztésű 
void gsort(void" p, size t n, size t sz, CFT cmp); // cmp C szerkesztésű 
J 
void isort(void" p, size t n, size t sz, FT cmp); // cmp Cx4 szerkesztésű 
void xsort(void"? p, size t n, size t sz, CFT cmp); // cmp C szerkesztésű 


extern "C" void ysort(void" p, size t n, size t sz, FT cmp); // cmp Cx4 szerkesztésű 


int compare(const void", const void"); // compareO Cxs54 szerkesztésű 
extern "C" int ccmp(const void", const void"); // ccmpO C szerkesztésű 


void (char? v, int sz) 


f 
gsort(v,sz, I,gcompare); — // hiba 
gsort(v,sz, 1,k ccmp); // rendben 


isort(v,sz, 1,k comparo); // rendben 
isort(v,sz, 1,k ccmp); // hiba 
J 


Egy olyan nyelvi változat, amelyben a C és C-t ugyanazt a függvényhívási módot használ- 
ja, nyelvi kiterjesztésként elfogadhatja a hibaként megjelölt eseteket. 
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9.3. Fejállományok használata 


A fejállományok használatának illusztrálására most bemutatjuk a számológép program 
(46.1, §8.2) néhány lehetséges fizikai elrendezését. 


9.3.1. Egyetlen fejállományos elrendezés 


Egy programot úgy bonthatunk a legegyszerűbben több fájlra, hogy a definíciókat megfe- 
lelő számú .c fájlba, a .c fájlok közötti kapcsolatot biztosító típusok deklarációit pedig 
egyetlen .A fájlba tesszük, melyet minden .c fájl beépít (4include). A számológép program 
esetében öt .c fájlt — lexer.c, barser.c, table.c, error.c és main.c — használhatnánk a függvé- 
nyek és adatleírások tárolására, és a dc.h fejállományban tárolhatnánk azoknak a neveknek 
a deklarációit, amelyek egynél több fájlban használatosak. 


A dc.h fejállomány így nézne ki: 
// dc.h: 


namespace Error f 
struct Zero divide f ); 


struct Syntax error f 

const char? p; 

Syntax error(const char" pfp- a; ) 
j; 


j 


finclude Sstring2 
namespace Lexer f 


enum Token value f 


NAME, NUMBER, END, 
PLUS- 4, MINUS- -- , MUL-"", DIV-/, 
PRINT-". , ASSIGN- IP-(G, RP-))! 


Í5. 
extern Token value curr. tok; 
extern double number. value; 


extern std::String string value; 


Token value get tokenO; 
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namespace Parser f 


double prim(bool get); // elemi szimbólumok kezelése 
double term(bool ge0; // szorzás és osztás 
double expr(bool geV); // összeadás és kivonás 


using Lexer::get token; 
using Lexer::curr. tok; 


J 
finclude cmap: 
extern std::mapcSstd::string, double: table; 


namespace Driver f 
extern int no of errors; 
extern std::istream? input; 
void skipO; 

J 


Minden változódeklarációban az extern kulcsszót használjuk annak biztosítására, hogy egy 
meghatározás ne forduljon elő többször is, amikor a dc.h-t a fájlokba beépítjük. Az egyes 
definíciók a megfelelő .c fájlban szerepelnek. 


A lényegi kód elhagyásával a lexer.c valahogy így néz ki: 


// lexer.c: 


finclude "dc.h" 
finclude Ciostream: 
include £cctype: 


Lexer::Töoken value Lexer::curr. tok; 
double Lexer::number value; 
std::string Lexer::string value; 


Lexer::Töoken value Lexer::get tokenO f /? ... "/) 


A fejállomány ilyen használata biztosítja, hogy a benne lévő minden deklaráció valamilyen 
ponton be legyen építve abba a fájlba, amely a hozzá tartozó kifejtést tartalmazza. A lexer.c 
fordításakor például a fordítóprogramnak a következő kód adódik át: 


namespace Lexer ( // a dc.h-ból 
AG 
Token value get tokenO; 


J 


MAT 
Lexer::Töoken value Lexer::get tokenO f /" ... "/) 
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Így a fordítóprogram biztosan észreveszi, ha egy névhez megadott típusok nem egysége- 
sek. Ha a get tokenO-t például Token value típusú visszatérési értékkel vezettük volna be, 
de int visszatérési értékkel definiáltuk volna, a lexer.c fordítása típusütközési vagy ,nem 
megfelelő típus" (type mismatch) hiba miatt nem sikerült volna. Ha egy definíció hiányzik, 
a szerkesztő fogja észrevenni a problémát, ha egy deklaráció, akkor valamelyik .c fájl for- 
dítása hiúsul meg. 


A parser.c fájl így fog kinézni: 
// parser.c: 
$include "dc.h" 
double Parser::prim(bool get) f /? ... "/) 


double Parser::term(bool gep ( /? ... "/) 
double Parser::expr(bool gep) f /? ... "/) 


A table.c pedig így: 
// table.c: 
finclude "dc.h" 


std::mapcstd::string, double: table; 


A szimbólumtábla nem más, mint egy standard könyvtárbeli map típusú változó. A fenti de- 
finíció a table-t globálisként határozza meg. Egy valóságos méretű programban a globális 
névtér efféle kis ,szennyeződései" felhalmozódnak és végül problémákat okoznak. Csak 
azért voltam itt ilyen hanyag, hogy lehetőségem legyen figyelmeztetni rá. 


A main.c fájl végül így fog kinézni: 
// main. c: 


finclude "dc.h" 
iinclude csstream: 


int Driver::no of" errors — 0; 
std::istream? Driver::input - O; 


void Driver::skipO £/ ... "/) 


int main(int argc, char? arg D€/5 ... ") 
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Ahhoz, hogy a program mainO függvényének ismerjék fel, a mainO-nek globális függ- 
vénynek kell lennie, ezért itt nem használtunk névteret. 


A program fizikai elrendezését valahogy így lehet bemutatni: 











csstream: cxcmap- Lstring2 Lcctypez CLiostream: 


























dc.h 


sz 


main.c barser.c table.c lexer.c 
































Észrevehetjük, hogy a felül lévő fejállományok mind a standard könyvtár fájljai. A program 
elemzésekor ezek a könyvtárak számos esetben kihagyhatók, mert széleskörűen ismertek 


és stabilak. A kis programoknál az elrendezés egyszerűsíthető, ha minden finclude utasí- 
tást közös fejállományba teszünk. 


Az egyetlen fejállományos fizikai részekre bontás akkor a leghasznosabb, ha a program ki- 
csi és részeit nem áll szándékunkban külön használni. Jegyezzük meg, hogy amikor névte- 
reket használunk, a dc.h-ban egyben a program logikai felépítését is ábrázoljuk. Ha nem 
használunk névtereket, a szerkezet homályos lesz, bár ezen a megjegyzések segíthetnek. 


A nagyobb programok egyetlen fejállományos elrendezése nem működik a hagyományos, 
fájl alapú fejlesztőkörnyezetekben. A közös fejállomány módosítása maga után vonja az egész 
program újrafordítását és nagy a hibalehetőség, ha több programozó is módosítja az egyetlen 
fejállományt. Hacsak nem fektetnek hangsúlyt a névterekkel és osztályokkal kapcsolatos 
programozási stílusra, a logikai felépítés a program növekedésével együtt romlani fog. 
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9.3.2. Több fejállományos elrendezés 


Egy másik fizikai elrendezés szerint minden logikai modulnak saját fejállománya lenne, 
amely leírja a modul által nyújtott szolgáltatásokat. Ekkor minden .c fájlhoz tartozik egy 
megfelelő .7 fájl, ami meghatározza a .c szolgáltatásait (felületét). Minden .c fájl beépíti a sa- 
ját .h fájlját, és rendszerint további olyan ./A fájlokat is, amelyek meghatározzák, mire van 
szüksége más modulokból ahhoz, hogy megvalósítsa a felületében közzétett szolgáltatáso- 
kat. Ez a fizikai elrendezés megegyezik a modul logikai felépítésével. A felhasználóknak 
szánt felületet a ./z fájl tartalmazza, a programozói felületegy . impl.h végződésű fájlban sze- 
repel, a modul függvény- és változódefiníciói stb. pedig a .c fájlokban vannak elhelyezve. 
Ily módon az elemzőt három fájl képviseli, felhasználói felületét pedig a parser.h nyújtja: 


// parser.h: 


namespace Parser ( // felület a felhasználóknak 
double expr(bool get); 


j 


Az elemzőt megvalósító függvények közös környezetét a parser. impl.h adja: 
// parser. impl.h: 


tinclude "parser.h" 
Ainclude "error.h" 
finclude "lexer.h" 


namespace Parser ( // felület a megvalósításhoz 
double prim(bool get); 
double term(bool ge); 
double expr(bool ge0); 
using Lexer::get token; 
using Lexer::curr. tok; 


j 


A parser.h felhasználói fejállományt azért építjük be, hogy a fordítóprogram ellenőrizhesse 
a következetességet (49.3.1. Az elemző függvényeket a barser.c fájlban együtt tároljuk 
azokra a fejállományokra vonatkozó finclude utasításokkal, melyekre a Parser függvényei- 
nek szüksége van: 


// parser.c: 


$include "parser. impl.h" 

tinclude "table.h" 

double Parser::prim(bool get) f /? ... "/) 
double Parser::term(bool geD £ / ... "/) 
double Parser::expr(bool gep) f / ... "/) 
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Az elemző és annak a vezérlő általi használata ábrával így mutatható be: 








Parser.h lexer.h error.h table.h 
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barser. impl.h 

















main.c Parser.c 








Ahogy vártuk, ez elég jól egyezik a §8.3.3-ban leírt logikai szerkezettel. Ha a table.h-t 
a parser. impl.h-ba építettük volna be a barser.c helyett, a szerkezetet még tovább egysze- 
rűsíthettük volna. A table.h azonban valami olyasmire példa, ami nem szükséges az elem- 
ző függvények közös környezetének kifejezéséhez, csak a függvények megvalósításainak 
van szüksége rá. Tulajdonképpen egyetlen függvény, a primO használja, így ha a függősé- 
geket valóban a lehető legkevesebbre szeretnénk csökkenteni, a primO-et tegyük külön .c 
fájlba és csak oda építsük be a table.h-t: 


barser.h lexer.h error.h table.h 









































Parser. impl.h 























barser.c brim.c 
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Ilyen alaposságra a nagyobb modulokat kivéve nincs szükség. A valóságos méretű modu- 
lok esetében gyakori, hogy további fájlokat építenek be ott, ahol egyes függvények számá- 
ra azok szükségesek. Továbbá nem ritka, hogy egynél több. impl.h fájl van, mivel a modul 
függvényeinek részhalmazai különböző közös környezetet igényelnek. 


Meg kell jegyeznünk, hogy az impli.h használata nem szabványos és még csak nem is gya- 
kori megoldás -— én egyszerűen így szeretek elnevezni dolgokat. 


Miért törődünk ezzel a bonyolultabb több fejállományos elrendezéssel? Nyilván sokkal ke- 
vesebb gondolkodást igényel, ha egyszerűen minden deklarációt bedobunk egy fejállo- 
mányba, mint ahogy azt a dc.h-nál tettük. 


A több fejállományos elrendezés olyan modulok és programok esetében hatásos, amelyek 
nagyságrendekkel nagyobbak, mint a mi apró elemzőnk és számológépünk. Alapvetően 
azért használtuk ezt az elrendezéstípust, mert jobban azonosítja a kapcsolatokat. Egy nagy 
program elemzésekor vagy módosításakor alapvető, hogy a programozó viszonylag kis 
kódrészletre összpontosíthasson. A több fejállományos elrendezés segít, hogy pontosan el- 
dönthessük, mitől függ az elemző kód, és hogy figyelmen kívül hagyhassuk a program töb- 
bi részét. Az egyetlen fejállományos elrendezés rákényszerít minket, hogy minden olyan 
deklarációt megnézzünk, amelyet valamelyik modul használ, és eldöntsük, hogy odaillő-e. 
A lényeg, hogy a kód módosítása mindig hiányos információk és helyi nézőpont alapján 
történik. A több fejállományos elrendezés megengedi, hogy sikeresen dolgozzunk , belül- 
ről kifelé", csak helyi szemszögből. Az egyetlen fejállományos elrendezés — mint minden 
más elrendezés, ahol egy globális információtár van a középpontban - felülről lefelé hala- 
dó megközelítést igényel, így örökké gondolkodnunk kell azon, hogy pontosan mi függ 
egy másik dologtól. 


A jobb összpontosítás azt eredményezi, hogy kevesebb információ kell a modul lefordítá- 
sához, így az gyorsabban történik. A hatás drámai lehet. Előfordul, hogy a fordítási idő ti- 
zedrészére csökken, pusztán azért, mert egy egyszerű függőségelemzés a fejállományok 
jobb használatához vezet. 


9.3.2.1. A számológép egyéb moduljai 


A számológép többi modulját az elemzőhöz hasonlóan rendezhetjük el. Ezek a modulok 
azonban olyan kicsik, hogy nem igényelnek saját impl.h fájlokat. Az ilyen fájlok csak ott 
kellenek, ahol egy logikai modul sok függvényből áll, amelyeknek közös környezetre van 
szükségük. 
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A hibakezelőt a kivételtípusok halmazára egyszerűsítettük, így nincs szükségünk az error.c-re: 
// error.h: 


namespace Error f 
struct Zero. divide ( ?;; 


struct Syntax error ( 


const char? p; 
Syntax errorcconst char" pfp- a; ) 


Az adatbeviteli kód (lexikai elemző, lexer) meglehetősen nagy és rendezetlen felületet 
nyújt: 


// lexer.h: 
finclude Sstring: 
namespace Lexer f 


enum Token value f 


NAME, NUMBER, END, 
PLUS- MINUS- -, MUL-", DIV-/, 
PRINT- ":, ASSIGN-z IP-(C, RP-))" 


jó 


extern Token value curr. tok; 
extern double number. value; 
extern std::String string value; 


Token value get tokenO; 


A lexer.h-n kívül a lexikai elemző az error.h-ra, az Ciostream:-re és a Cctype:-ban meg- 
adott, a karakterek fajtáit eldöntő függvényekre támaszkodik: 


// lexer.c: 


finclude "lexer.h" 
finclude "error.h" 
finclude Ciostream: 
áinclude £cctype: 
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Lexer::Token value Lexer::curr. tok; 
double Lexer::number value; 
std::string Lexer::string value; 


Lexer::Token value Lexer::get tokenO f£ /? ... "/) 


Az error.h $include utasításait külön tehettük volna, a Zexer-hez tartozó . impl.h fájlba, ez 
azonban túlzás egy ilyen kis program esetében. 


A modul megvalósításában szokásos módon építjük be (finclude) a modul által nyújtott fe- 
lületet — ebben az esetben a lexer.h-t —, hogy a fordítóprogram ellenőrizhesse a következe- 
tességet. 


A szimbólumtábla alapvetően önálló, bár a standard könyvtárbeli cmap: fejállomány hasz- 
nálatával számos érdekes dolog kerülhet bele, hogy hatékonyan valósíthassa meg a map 
sablonosztályt: 


// table.h: 


tinclude cmap: 
finclude Sstring2 


extern std::mapcstd::string, double: table; 


Mivel feltesszük, hogy az egyes fejállományok több .c fájlba is bele lehetnek építve, a table 


a table.h közötti különbség csak az extern kulcsszó: 
// table.c: 
tinclude "table.h" 
std::mapcstd::string, double: table; 

A vezérlő tulajdonképpen mindenre támaszkodik: 
// main.c: 
$include "parser.h" 
$include "lexer.h" 


finclude "error.h" 
ainclude "table.h" 
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namespace Driver f 
int no of errors; 
std::istream" input; 
void skipO; 

J 


finclude csstream: 


int main(int argc, char" arg D€/5 ... "/) 


Mivel a Driver névteret kizárólag a mainO használja, a main.c-be tesszük azt. Külön is sze- 
repelhetne driver.h fájlként, amit az include utasítással beépítünk. 


A nagyobb programokat rendszerint megéri úgy elrendezni, hogy a vezérlőnek kevesebb 
közvetlen függősége legyen. Gyakran ésszerű az olyan műveletekből is minél kevesebbet 
alkalmazni, amit a main tesz, nevezetesen hogy meghív egy külön forrásfájlban lévő ve- 
zérlő függvényt. Ez különösen fontos olyan kódok esetében, amelyeket könyvtárként aka- 
runk használni. Ekkor ugyanis nem támaszkodhatunk a mainO-ben megírt kódra és fel kell 
készülnünk arra is, hogy különböző függvényekből hívják meg kódunkat (49.6[8D. 


9.3.2.2. A fejállományok használata 


A programban használt fejállományok (header file) száma több tényezőtől függ. Ezen té- 
nyezők közül sok inkább a rendszer fájlkezeléséből adódik és nem a C--4-ból. Például, ha 
szövegszerkesztő programunk nem képes arra, hogy több fájlt nézzünk vele egyszerre, ak- 
kor nem előnyös sok fejállományt használnunk. Hasonlóan, ha 20 darab 50 soros fájl olva- 
sása észrevehetően több időt igényel, mint egyetlen 1000 soros fájlé, akkor kétszer is gon- 
doljuk meg, mielőtt egy kis projektben a több fejállományos stílust használjuk. 


Néhány figyelmeztetés: egy tucatnyi fejállomány (természetesen a szokásos fejállomá- 
nyokkal együtt, melyeket gyakran százas nagyságrendben számolhatunk) a program vég- 
rehajtási környezete számára rendszerint még kezelhető. Ha azonban egy nagy program 
deklarációit logikailag a lehető legkisebb fejállományokra bontjuk (például úgy, hogy min- 
den szerkezet deklarációját külön fájlba tesszük), könnyen egy több száz fájlból álló, kezel- 
hetetlen zűrzavar lehet az eredmény. 


Nagy projekteknél persze elkerülhetetlen a sok fejállomány. Az ilyeneknél több száz fájl 
(nem számolva a szokásos fejállományokat) az általános. Az igazi bonyodalom ott kezdő- 
dik, amikor elérik az ezres nagyságrendet. A fent tárgyalt alapvető módszerek ekkor is al- 
kalmazhatók, de az állományok kezelése sziszifuszi feladattá válik. Emlékezzünk, hogy 
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a valódi méretű programoknál az egyetlen fejállományos elrendezést általában nem választ- 
hatjuk, mert az ilyen programok rendszerint eleve több fejállományt tartalmaznak. A kétfaj- 
ta elrendezési módszer között a program alkotórészeinek létrehozásakor kell (néha több- 
ször is) választanunk. 


Igazán nem is a mi ízlésünkre van bízva, hogy az egyetlen és a több fejállományos elrende- 
zés közül válasszunk. Ezek olyan egymást kiegészítő módszerek, melyeket mindig figye- 
lembe kell vennünk a lényegi modulok tervezésekor, és újra kell gondolnunk azokat, 
ahogy a rendszer fejlődik. Rendkívül fontos emlékeznünk arra, hogy egy felület nem szol- 
gálhat minden célra ugyanolyan jól. Rendszerint megéri különbséget tenni a fejlesztői és 
a felhasználói felület között. Ezenkívül sok nagyobb program szerkezete olyan, hogy cél- 
szerű a felhasználók többségének egyszerű, a tapasztaltabb felhasználóknak pedig terjedel- 
mesebb felületet nyújtani. A tapasztalt felhasználók felületei (a ,teljes felületek") sokkal 
több szolgáltatást építenek be, mint amennyiről egy átlagos felhasználónak tudnia kell. Va- 
lójában az átlagos felhasználó felületét úgy határozhatjuk meg, hogy nem építjük be azokat 
a fejállományokat, amelyek olyan szolgáltatásokat írnak le, amelyek ismeretlenek lennének 
az átlagos felhasználó számára. Az ,átlagos felhasználó" kifejezés nem lekicsinylő. Ahol 
nem muszáj szakértőnek lennem, jobban szeretek átlagos felhasználó lenni. Így ugyanis 
kevesebb a veszekedés. 


9.3.3. , Allomány-őrszemek" 


A több fejállományos megközelítés gondolata az, hogy minden logikai modult következe- 
tes, önálló egységként ábrázoljunk. A program egészének szempontjából nézve viszont 
azon deklarációk többsége, melyek ahhoz kellenek, hogy minden logikai egység teljes le- 
gyen, felesleges. Nagyobb programoknál az ilyen fölösleg (redundancia) hibákhoz vezet- 
het, amint egy osztályleírást vagy helyben kifejtett függvényeket tartalmazó fejállományt 
ugyanabban a fordítási egységben (49.2.3) kétszer építünk be az $include-dal. 


Két választásunk lehet. 


1. Átszervezhetjük a programunkat, hogy eltávolítsuk a fölösleget, vagy 
2. találunk valamilyen módot arra, hogy a fejállományok többszöri beépítése 
megengedett legyen. 


Az első megközelítés — ami a számológép végső változatához vezetett — fárasztó és valósá- 
gos méretű programoknál gyakorlatilag kivitelezhetetlen. A fölöslegre azért is szükségünk 
van, hogy a program egyes egységei elkülönülten is érthetőek legyenek. A fölös sinclude- 


ok kiszűrése és az ennek eredményeképpen létrejött egyszerűsített program nagyon elő- 
nyös lehet mind logikai szempontból, mind azáltal, hogy csökken a fordítási idő. Az összes 
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előfordulás megtalálása azonban ritkán sikerül, így alkalmaznunk kell valamilyen eszközt, 
ami megengedi a fölös sinclude-ok jelenlétét. Lehetőleg szisztematikusan kell használ- 
nunk, mert nem tudhatjuk, hogy a felhasználó mennyire alapos elemzést tart érdemesnek. 


A hagyományos megoldás az, hogy a fejállományokba , állomány-őrszemeket" (beépítés- 
figyelőket, include-guards) illesztünk: 


// error.h: 


eifndef CALC ERROR H 
édefine CALG ERROR H 


namespace Error f 
V/KESES 
J 


fendif // CALC ERROR H 


A fájlnak az fifndefés az sendif közötti tartalmát a fordítóprogram nem veszi figyelembe, 
ha a CALC ERROR H már definiált. Ezért amikor a fordítóprogram az error.h-val először ta- 
lálkozik, beolvassa annak tartalmát, a CAZC ERROR H pedig értéket kap. Ha ismét talál- 
kozna vele a fordítás során, másodszor már nem fogja figyelembe venni. Ez makrókkal va- 
ló ügyeskedés, de működik és mindenütt jelen van a C és C4- világában. A standard könyv- 
tár fejállományainak mindegyike tartalmaz állomány-őrszemeket. 


A fejállományokat mindenféle környezetben használják, a makrónevek ütközése ellen pe- 
dig nincs névtér védelem. Az állomány-őrszemeknek ezért hosszú és csúnya neveket szok- 
tam választani. 


Amint a programozó hozzászokik a fejállományokhoz és az állomány-őrszemekhez, hajla- 
mos közvetlenül vagy közvetve sok fejállományt beépíteni. Ez nem kívánatos, még azoknál 
a C4-4-változatoknál sem, melyek optimalizálják a fejállományok feldolgozását. Szükségte- 
lenül hosszú fordítási időt okozhatnak és számos deklarációt és makrót elérhetővé te- 
hetnek, ami kiszámíthatatlanul és kedvezőtlenül befolyásolhatja a program jelentését. Csak 
akkor építsünk be fejállományokat, amikor tényleg szükség van rá. 
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9.4. Programok 


A program külön fordított egységek gyűjteménye, melyet a szerkesztőprogram egyesít. 
Minden, ebben a gyűjteményben használt függvénynek, objektumnak, típusnak stb. egye- 
di meghatározással (definícióval) kell rendelkeznie (44.9, 49.2.3) és pontosan egy mainO 
nevű függvényt kell tartalmaznia (43.29. A program által végzett fő tevékenység a mainŐO 
meghívásával kezdődik és az abból való visszatéréssel ér véget. A mainŐ által visszaadott 
int érték lesz a program visszatérési értéke, amit a mainO-t meghívó rendszer megkap. 


Ezen az egyszerű meghatározáson a globális változókat tartalmazó (§10.4.9) vagy el nem 
kapott kivételt (§14.7) kiváltó programok esetében finomítanunk kell. 


9.4.1. Kezdeti értékadás nem lokális változóknak 


Elvileg a függvényeken kívül megadott, nem lokálisnak számító változók (azaz a globális, 
névtér-, vagy static osztályváltozók) a mainO meghívása előtt, a fordítási egységben 
definiciójuk sorrendjében kapnak kezdőértéket (410.4.9). Ha egy ilyen változónak nincs 
pontosan meghatározott (explicit) kezdőértéke, akkor a típusának megfelelő alapértelme- 
Zett értékkel töltődik fel (§10.4.2). A beépített típusok és felsorolások esetében az alapértel- 


mezett kezdőérték a 0: 


double x — 2; // nem lokális változók 
double y; 
double sax - sgrt(xty); 


Itt az xés az y az sgx előtt kap kezdőértéket, így az sgrt(2) hívódik meg. 


A különböző fordítási egységekben lévő globális változók kezdőértékkel való ellátásának 
sorrendje nem kötött, következésképpen nem bölcs dolog ezeknél a kezdőértékek között 
sorrendi függőségeket létrehozni. Továbbá nem lehetséges olyan kivételt sem elkapni, amit 
egy globális változó kezdeti értékadása váltott ki (414.7). Általában az a legjobb, ha minél 
kevesebb globális változót használunk; főleg a bonyolult kezdeti értékadást igénylő globá- 
lis változók használatát kell korlátoznunk. 


A különböző fordítási egységekben lévő globális változók kezdeti értékkel való feltöltésének 
sorrendjét számos módon kényszeríthetjük ki, de nincs köztük olyan, amely egyszerre , hor- 
dozható" és hatékony is lenne. Főleg a dinamikus csatolású könyvtárak (DLL) nem képesek 


9. Forrásfájlok és programok 289 


a bonyolult függőségekkel rendelkező globális változókkal boldogan együtt élni. Globális 
változók helyett gyakran használhatunk referenciát visszaadó függvényeket: 


intik use countO 


( 
static int uc — 0; 
return uc; 


J 


A use countO hívás most globális változóként működik, kivéve, hogy első használatakor 
kap kezdőértéket (45.59: 


void JO 
( 


cout c£ ttuse count; // növelés és kiírás 
Hetés 
4 


A nem lokális statikus változók kezdeti értékadását bármilyen eljárás vezérelheti, amit az 
adott nyelvi változat arra használ, hogy elindítsa a C-t programot. Csak akkor garantált, 
hogy a módszer megfelelően működik, ha a mainO végrehajtására sor kerül, ezért el kell 
kerülnünk azon nem lokális változók használatát, melyek futási idejű kezdeti értékadást 
igényelnek olyan Cs- kódban, amit nem C-t- program használ. 

Jegyezzük meg, hogy a kezdőértéket konstans kifejezésektől kapó változók (4C.5) nem 
függhetnek más fordítási egységben levő objektumok értékétől és nem igényelnek futási 
idejű kezdeti értékadást, így minden esetben biztonságosan használhatók. 


9.4.1.1. A program befejezése 


A programok futása számos módon érhet véget: 


A mainO-ből való visszatéréssel 
Az exit meghívásával 

Az abortO meghívásával 

El nem kapott kivétel kiváltásával 


..... 


Továbbá többféle hibás felépítés és nyelvi változattól függő módszer létezik arra, hogy egy 
program összeomoljon. Ha a program befejezésére a standard könyvtárbeli exitO függvényt 
használjuk, akkor meghívódnak a létrehozott statikus objektumok destruktorai (410.4.9, 
§10.2.4). Ha azonban a program a standard könyvtár abortÓ függvényét használja, 


290 Alapok 


a destruktorok meghívására nem kerül sor. Jegyezzük meg: ez azt is jelenti, hogy az exitO 
nem fejezi be rögtön a programot; destruktorban való meghívása végtelen ciklust eredmé- 
nyezhet. Az exitŐ függvény típusa 


void exit(int); 


A mainO visszatérési értékéhez (§3.2) hasonlóan az exit paramétere is visszaadódik 
, a rendszernek" a program visszatérési értékeként. A nulla sikeres befejezést jelent. 


Az exit meghívása azt jelenti, hogy a hívó függvény lokális változóinak és az azt hívó függ- 
vények hasonló változóinak destruktorai nem hívódnak meg. A lokális objektumok megfe- 
lelő megsemmisítését (414.4.7) egy kivétel , dobása" és elkapása biztosítja. Emellett az exiízÓ 
meghívása úgy fejezi be a programot, hogy az exitO hívójának nem ad lehetőséget arra, 
hogy megoldja a problémát. Ezért gyakran az a legjobb, ha a környezetet egy kivétel kivál- 
tásával elhagyjuk, és megengedjük egy kivételkezelőnek, hogy eldöntse, mi legyen a továb- 
biakban. A C (és C-t) standard könyvtárának atexitO függvénye lehetőséget ad arra, hogy 
kódot hajthassunk végre a program befejeződésekor: 


void my cleanupO; 
void somewhereO 


if (atexi(rkmy cleanup)—--0) ( 
// normál programbefejezéskor a my cleanup hívódik meg 


J 


else ( 
// hoppá: túl sok atexit függvény 
j 


j 


Ez nagyban hasonlít a globális változók destruktorainak a program befejeződésekor törté- 
nő automatikus meghívásához (410.4.9, §10.2.4). Jegyezzük meg, hogy az atexit0 paramé- 
terének nem lehet paramétere és nem adhat vissza értéket. Az atexit függvények számát az 
adott nyelvi változat korlátozza; a függvény nem nulla érték visszaadásával jelzi, ha ezt 
a korlátot elérték. Ezek a korlátozások az atexit0-et kevésbé használhatóvá teszik, mint 
amilyennek első pillantásra látszik. 


Az atexit(f) meghívása előtt létrehozott objektum destruktora az fmeghívása után fog meg- 
hívódni, az atexit(f) meghívása után létrehozott objektum destruktora pedig az fmeghívá- 
sa előtt. 
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9.5. Tanácsok 


[1] 


[2] 


[3] 


[4] 
[5] 
[6] 
[7] 
[8] 


[91 
[10] 
[11] 
[12] 


Használjuk fejállományokat a felületek ábrázolására és a logikai szerkezet 
kihangsúlyozására. 49.1, §49.3.2. 

Abban a forrásfájlban építsük be őket (finclude), amelyben függvényeiket 
kifejtjük. §49.3.1. 

Ne adjunk meg globális egyedeket ugyanazzal a névvel és hasonló, de különbö- 
ző jelentéssel különböző fordítási egységekben. §9.2. 

Kerüljük a fejállományokban a nem helyben kifejtendő függvényeket. §9.2.1. 
Csak globális hatókörben és névterekben használjuk az $include-ot. §9.2.1. 
Csak teljes deklarációkat építsünk be. §9.2.1 

Használjunk , állomány-őrszemeket". §9.3.3. 

A C fejállományokat névterekben építsük be, hogy elkerüljük a globális neve- 
ket. §9.3.2. 

Tegyük a fejállományokat különállóvá. 49.2.3. 

Különböztessük meg a fejlesztői és a felhasználói felületet. 49.3.2. 
Különböztessük meg az átlagos és a tapasztalt felhasználók felületét. §9.3.2. 
Kerüljük az olyan nem lokális objektumok használatát, amelyek futási idejű kez- 
deti értékadást igényelnek olyan kódban, amit nem C-t program részeként 
szándékozunk felhasználni. §9.4.1. 


9.6. Gyakorlatok 


1. 


(2) Találjuk meg, hol tárolja rendszerünk a szabványos fejállományokat. Íras- 
suk ki neveiket. Van-e olyan nem szabványos fejállomány, amely ezekkel együtt 
tárolódik? Be lehet-e építeni nem szabványos fejállományokat a c: jelölést 
használva? 

(2) Hol tárolódnak a nem szabványos , foundation" könyvtárak fejállományai? 
(25) Írjunk programot, amely beolvas egy forrásfájlt és kiírja a beépített fájlok 
neveit. Használjunk behúzást a beépített fájlok által beépített fájlok kiírásakor, 

a befoglalás mélységének jelölésére. Próbáljuk ki a programot néhány valódi 
forrásfájlon (hogy elképzelésünk legyen a beépített információ nagyságáró]. 
(3) Módosítsuk az előbbi programot, hogy minden beépített fájlra kiírja a meg- 
jegyzések és a nem megjegyzések sorainak számát, illetve a nem megjegy- 
zésként szereplő, üreshelyekkel elválasztott szavak számát. 
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. C2,5) A külső beépítésfigyelő olyan programelem, amely a megfigyelt fájlon kí- 


vül végzi az ellenőrzést, és fordításonként csak egyszer végez beépítést. Készít- 
sünk egy ilyen szerkezeti elemet, tervezzünk módszert a tesztelésére, és fejtsük 
ki előnyeit és hátrányait a §9.3.3-ban leírt ,állomány-őrszemekkel" szemben. 
Van-e a külső beépítésfigyelőknek bármilyen jelentős futási időbeli előnye 

a rendszerünkben? 


. C3) Hogyan valósul meg a dinamikus csatolás (szerkesztés) a rendszerünkben? 


Milyen megszorítások vonatkoznak a dinamikusan szerkesztett kódra? Milyen 
követelményeknek kell, hogy megfeleljen a kód, hogy dinamikusan csatolható 
legyen? 


. 3) Nyissunk meg és olvassunk be 100 fájlt, melyek mindegyike 1500 karaktert 


tartalmaz. Nyissunk meg és olvassunk be egy 150 000 karakterből álló fájlt. 
Tipp: nézzük meg a példát a §21.5.1 pontban. Van-e eltérés a teljesítményben? 
Hány fájl lehet egyszerre megnyitva rendszerünkben? Válaszoljuk meg ezeket 
a kérdéseket a beépített fájlok használatával kapcsolatban is. 


. (2) Módosítsuk a számológépet, hogy meg lehessen hívni a mainO-ből vagy 


más függvényből is, egy egyszerű függvényhívással. 


. (2) Rajzoljuk meg a , modulfüggőségi diagramokat" (49.3.2) a számológép azon 


változataira, melyek az errorO-t használták kivételek helyett. (48.2.2). 


Második rész 


Absztrakciós módszerek 


Ebben a részben azzal foglalkozunk, milyen lehetőségeket nyújt a Ct-4 nyelv új típusok 


meghatározására és használatára, illetve bemutatjuk az összefoglaló néven objektumorien- 


tált programozásnak és általánosított (generikus) programozásnak nevezett eljárásokat. 


10. 
11. 
124; 
13. 
14. 
15. 


Fejezetek 


Osztályok 

Operátorok túlterhelése 
Származtatott osztályok 
Sablonok 
Kivételkezelés 
Osztályhierarchiák 


,:.. nincs nehezebb, kétesebb kimenetelű, veszélyesebb dolog, mint új törvények bevezeté- 
séért síkraszállni. Mert ellenségei azok, akiknek a régi törvények hasznára vannak, azok pe- 
dig, akiknek az új rendelkezések szolgálnak hasznukra, pusztán lagymatag védelmezői..." 


Niccolo Machiavelli 
(A fejedelem (vi), Lutter Éva fordítása) 
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Osztályok 


, Ezek a típusok nem , elvontak"; 
ugyanannyira valóságosak, 
mint az int és a float." 

(Doug Mclilroy) 


Fogalmak és osztályok e Osztálytagok s Az elérhetőség szabályozása e Konstruktorok e Sta- 
tikus tagok s Alapértelmezett másolás s const tagfüggvények e this s struct-ok s Osztályon 
belüli függvénydefiníciók e Konkrét osztályok s Tagfüggvények és segédfüggvények s Ope- 
rátorok túlterhelése s A konkrét osztályok használata s Destruktorok s Alapértelmezett 
konstruktorok e Lokális változók e Felhasználói másolás s mzew és delete s Tagobjektu- 
mok e Tömbök "s Statikus tárolás e Ideiglenes változók e Uniók s Tanácsok s Gyakorlatok 


10.1. Bevezetés 


A Cs nyelv osztályai azt a célt szolgálják, hogy a programozó a beépített adattípusokkal 
azonos kényelmi szinten használható új adattípusokat hozhasson létre. Ezenkívül az örök- 
lődés (12. fejezet) és a sablonok (13. fejezet) segítségével úgy szervezhetjük az egymással 
kapcsolatban álló osztályokat, hogy kapcsolataikat hatékonyan használhassuk ki. 
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A típus egy fogalom konkrét ábrázolása. A Ct-4 beépített //oat típusa például a -, -, " stb. 
műveleteivel együtt a valós szám matematikai fogalmának egy megközelítése. Az osztály 
egy felhasználói típus. Azért tervezünk új típust, hogy meghatározzunk egy fogalmat, 
amelynek nincs közvetlen megfelelője a nyelv beépített típusai között. Lehet például 
Trunk line típusunk egy telefonos kapcsolatokat kezelő programban, Explosion típusunk 
egy videójáték számára, vagy listcParagraph: típusunk egy szövegszerkesztő programban. 
Egy programot könnyebb megérteni és módosítani, ha abban az általa kezelt fogalmaknak 
megfelelő típusok szerepelnek. Ha a programozó alkalmas osztályokat használ, a program 
tömörebb lesz, ráadásul sokféle kódelemző eljárás használata válik lehetővé. A fordítóprog- 
ram például felderítheti az objektumok nem szabályos használatát, amit másként csak egy 
alapos ellenőrzés során fedezhetnénk fel. 


Új típus definiálásakor az alapvető szempont a megvalósítás véletlenszerű, esetleges rész- 
leteinek (például a tárolandó adatok elrendezésének) elválasztása a típus helyes használa- 
tához alapvetően szükséges tulajdonságoktól, például az adatokat elérő függvények teljes 
listájától. Ez az elválasztás legjobban úgy fejezhető ki, ha az adott típus adatszerkezetét érin- 
tő összes külső használatot és belső rendrakó függvényt csak az adott típusra vonatkozó 
programozási felületen keresztül tesszük elérhetővé. Ez a fejezet a viszonylag egyszerű, 
, konkrét" felhasználói típusokkal foglalkozik. Ideális esetben ezek csak létrehozásuk mód- 


jukban különböznek a beépített típusoktól, a használat módjában nem. 


10.2. Osztályok 


Az osztály (class) a programozó által meghatározott, más néven felhasználói típus. Az aláb- 
biakban az osztályok meghatározásának, illetve az osztályba tartozó objektumok létrehozá- 
sának és használatának főbb eszközeit mutatjuk be. 


10.2.1. Tagfüggvények 


Vizsgáljuk meg, hogyan ábrázolnánk a , dátum" fogalmát egy Date adatszerkezettel (struk- 
túrával, strucD0) és egy sor, ilyen változókat kezelő függvénnyel: 


struct Date ( // ábrázolás 
int d, m, y; 


J; 
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void init date(Datekg d, int, int, int); // kezdeti értékadás d-nek 
void add yearDateg d, int n); // n évet ad d-hez 

void add month(Dateg d, int n); // n hónapot ad d-hez 
void add day(Dateg d, int n); // n napot ad d-hez 


Az adattípus és ezen függvények között nincs kifejezett kapcsolat. Ilyen kapcsolatot azáltal 
hozhatunk létre, hogy a függvényeket tagfüggvényekként adjuk meg: 


struct Date f( 


int d, m, y; 

void init(int dd, int mm, int yy); // kezdeti értékadás 
void add yearCGint n); // n év hozzáadása 
void add montl(int n); / n hónap hozzáadása 
void add dayCint n); // n nab hozzáadása 


H 


Az osztálydefiníción belül bevezetett függvényeket (a struct is osztály, §10.2.8) tagfüggvé- 
nyeknek hívjuk. A tagfüggvényeket az adatszerkezetek tagjainak elérésére vonatkozó szo- 
kásos formában alkalmazhatjuk és csak megfelelő típusú objektumra: 


Date my birthday; 


void JO 


( 
Date today; 


today.init(16, 10, 19909; 
my birthday.init(30, 12,19509; 


Date tomorrow - today; 


tomorrow.add day(1); 
VES 


Minthogy a különböző adatszerkezeteknek azonos nevű függvényeik is lehetnek, a tag- 
függvények meghatározásakor meg kell adnunk az adatszerkezet nevét is: 


void Date::init(int dd, int mm, int yy) 


d - dd; 
m - mm; 
YI; 


J 
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A tagfüggvényekben a tagokat az objektum kifejezett megadása nélkül is használhatjuk. Ek- 
kor a név azon objektum megfelelő tagjára vonatkozik, amelyre a tagfüggvényt meghívtuk. 
Amikor például a Date::initO) tagfüggvényt alkalmazzuk a today változóra, az m-mm érték- 
adás a today.m változóra vonatkozik. Ha ugyanezt a tagfüggvényt a my birthday változó- 
ra alkalmaznánk, az m-mm értékadás a my birthday.m változóra vonatkozna. A tagfügg- 
vény mindig , tudja", hogy milyen objektumra hívták meg. 


A 


class X f ... 3; 


kifejezést osztálydefiníciónak hívjuk, mert egy új típust határoz meg. Történeti okokból az 
osztálydefiníciót néha osztálydeklarációként említik. Azon deklarációkhoz hasonlatosan, 
amelyek nem definíciók, az osztálydefiníciók az $include utasítás felhasználásával több for- 
rásállományban is szerepeltethetők, feltéve, hogy nem sértjük meg az egyszeri definiálás 
szabályát (49.2.3). 


10.2.2. Az elérhetőség szabályozása 

A Date előző pontbeli deklarációja azon függvények halmazát adja meg, melyekkel a Date 
típusú objektumot kezelhetjük. Ebből azonban nem derül ki, hogy kizárólag ezek lehetnek 
mindazok a függvények, amelyek közvetlenül függnek a Date típus ábrázolásától és köz- 
vetlenül elérhetik az ilyen típusú objektumokat. A megszorítást úgy fejezhetjük ki, ha szruct 
helyett class-t használunk: 


class Date f( 


int d, m, y; 

bublic: 
void init(int dd, int mm, int yy); // kezdeti értékadás 
void add year(int n); // n év hozzáadása 
void add month(int n); // n hónap hozzáadása 
void add day(int n); // n nap hozzáadása 


Jo 


A public címke két részre osztja az osztály törzsét. Az első, privát (private) részbeli neveket 
csak a tagfüggvények használhatják. A második, nyilvános (public) rész az osztály nyilvá- 
nos felülete. A szruct szerkezetek egyszerűen olyan osztályok, melyekben a tagok alapér- 
telmezett elérhetősége nyilvános (§10.2.8). A tagfüggvényeket a megszokott módon 
definiálhatjuk és használhatjuk: 
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inline void Date::add. yearGint n) 


( 
J 


Mindazonáltal a nem tag függvények a privát tagokat nem használhatják: 


yt-N 


void timewarp(Datekg d) 


dy-- 200, — // hiba: Date::y privát 
j 


Számos előnnyel jár, ha a tagok elérhetőségét egy pontosan megadott lista függvényeire 
korlátozzuk. Például, ha egy hiba miatt a Date érvénytelen értéket kap (mondjuk 1985. de- 
cember 36.-át), akkor biztosak lehetünk abban, hogy ez a hiba csak valamelyik tagfügg- 
vényben lehet. Ebből következik, hogy a hibakeresés első szakasza, a hiba helyének beha- 
tárolása már azelőtt megtörténik, hogy a program egyáltalán lefutna. Ez egyik esete annak 
az általános megfigyelésnek, hogy az osztály viselkedésének bármilyen módosítása csakis 
a tagfüggvények megváltoztatásával érhető el. Például ha megváltoztatjuk egy osztály adat- 
ábrázolását, akkor elég a tagfüggvényeket ennek megfelelően módosítanunk. Az osztályt 
használó kód közvetlenül csak az osztály nyilvános felületétől függ, ezért nem kell újraírni 
(bár lehet, hogy újra kell fordítani). A másik előny, hogy a leendő felhasználónak elég a tag- 
függvények meghatározását tanulmányoznia ahhoz, hogy megtudja, hogyan lehet használ- 
ni az osztályt. 


A privát tagok védelme az osztálytagok név szerinti elérhetőségének korlátozásán múlik, 
ezért a címek megfelelő kezelésével vagy pontosan meghatározott típuskonverzióval 
megkerülhető. Ez persze csalás. A C4- a véletlen hibák ellen véd, nem a védelmi rendszer 
tudatos megkerülése, a csalás ellen. Egy általános célú nyelvben csak hardverszinten lehet- 
ne a rosszindulatú használat ellen védekezni, és igazi rendszerekben még ez is nehezen ki- 
vitelezhető. 


Az initő függvényt részben azért vettük fel, mert általában célszerű, ha van egy, az objek- 
tumnak értéket adó függvényünk, részben pedig azért, mert az adattagok priváttá tétele mi- 
att erre kényszerültünk. 


10.2.3. Konstruktorok 


Az initŐ-hez hasonló függvények használata az objektumok kezdeti értékadására nem ele- 
gáns és hibák forrása lehet. Minthogy sehol sincs lefektetve, hogy egy objektumnak kezdő- 
értéket kell adni, a programozó elfelejtheti azt — vagy éppen többször is megteheti (mind- 
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két esetben egyformán végzetes következményekke)]. Jobb megoldás, ha lehetővé tesszük 
a programozónak, hogy megadjon egy olyan függvényt, melynek célja kifejezetten az ob- 
jektumok előkészítése. Mivel az ilyen függvény létrehozza az adott típusú értékeket, 
konstruktornak (vagyis létrehozónak, constructor) hívjuk. A konstruktort arról ismerjük 
meg, hogy ugyanaz a neve, mint magának az osztálynak: 


class Date f( 
Mazó 


DateCGint, int, int); // konstruktor 


J; 


Ha egy osztály rendelkezik konstruktorral, akkor minden, ebbe az osztályba tartozó objek- 


tum kap kezdőértéket. Ha a konstruktornak paraméterekre van szüksége, azokat meg kell 
adni: 


Date today - Date(23,6,1983); 


Date xmas(25, 12, 1990); // rövidített forma 
Date my birthday; // hiba: nincs kezdőérték 
Date release1 OC(10,129; // hiba: a harmadik paraméter hiányzik 


Gyakran célszerű, ha a kezdeti értékadás többféleképpen is lehetséges. Ezt úgy érhetjük el, 
ha többféle konstruktor áll rendelkezésre: 


class Date ( 


int d, m, y; 
bublic: 
RE 
DateCint, int, int); // nap, hónap, nap 
DateCGint, int); // nap, hónap, aktuális év 
DateGinY; // nap, aktuális hónap és év 
DateO; // alapértelmezett Date: mai dátum 
DateC(const char"); // a dátum karakterlánccal ábrázolva 


J; 
A konstruktorokra ugyanazok a túlterhelési szabályok vonatkoznak, mint más függvények- 
re (47.49. Amíg a konstruktorok kellően különböznek a paraméterek típusaiban, a fordító- 
program ki fogja tudni választani, melyiket kell az egyes meghívásokkor alkalmazni: 


Date today (49; 

Date julyá( July 4, 1983"; 

Date guyC5 Nov"); 

Date now; // alapértelmezett kezdeti értékadás az aktuális dátummal 


A Date példa esetében megfigyelhetjük a konstuktorok , elburjánzását", ami általános jelen- 
ség. A programozó egy osztály tervezésekor mindig kísértést érez új és új függvényekkel 


bővíteni azt, mondván, valakinek úgyis szüksége lesz rájuk. Több gondot igényel ugyanis 
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mérlegelni, mire van igazán szükség és arra szorítkozni. Ez az odafigyelés ugyanakkor álta- 
lában kisebb és érthetőbb programokhoz vezet. Az egymással rokon függvények számának 
csökkentésére az egyik mód az alapértelmezett paraméter-értékek használata (§7.5). A Date 
osztály paramétereinek például egy olyan alapértelmezett értéket adhatunk, melynek jelen- 
tése: vegyük az alapértelmezett today-t". 


class Date ( 


int d, m, y; 
bublic: 
Date(int dd -0O, int mm —0, int yy -09; 
VI sa 
J; 
Date:: DateC(int dd, int mm, int yy) 
( 
d - dd ? dd : today.d; 
m - mm ? mm : today.m; 
y7yy? gy : today.y; 
// ellenőrizzük, hogy Date érvényes dátum-e 
j 


Ha egy paraméter-értéket az alapértelmezett érték jelzésére használunk, annak kívül kell es- 
nie a lehetséges értékek halmazán. A day (nap) és month (hónap) paraméterek esetében ez 
a halmaz világosan meghatározható, a year (év) mezőnél azonban a zéró érték nem esik 
nyilvánvalóan a halmazon kívülre. Szerencsére az európai naptárban nincs 0-dik év; az idő- 


számításunk utáni első év (year-- 7) közvetlenül az időszámításunk előtti első év (vear-—-D 
után következik. 


10.2.4. Statikus tagok 


A Date típushoz tartozó kényelmes alapértelmezett értéket egy jelentős rejtett probléma 
árán hoztuk létre: Date osztályunk a today nevű globális változótól függ. Így az osztály csak 
akkor használható, ha a today változót definiáltuk és minden kódrészletben megfelelően 
használjuk. Ez a fajta megszorítás az osztályt az eredeti környezeten kívül használhatatlan- 
ná teszi. A felhasználóknak túl sok kellemetlen meglepetésben lesz részük, amikor ilyen 
környezetfüggő osztályokat próbálnak használni és a kód módosítása is problematikus lesz. 
Ezzel az egy ,kis globális változóval" még talán megbirkózunk, de ez a stílus vezet az ere- 
deti programozón kívül más számára használhatatlan kódhoz. Kerüljük el! 


Szerencsére a kívánt célt elérhetjük a nyilvánosan elérhető globális változó jelentette teher- 
tétel nélkül is. Az olyan változókat, melyek egy osztályhoz tartoznak, de annak objektu- 
maihoz nem, statikus tagnak nevezzük. A statikus tagokból mindig pontosan egy példány 
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létezik, nem pedig objektumonként egy, mint a közönséges, nem statikus adattagokból. Eh- 
hez hasonlóan az olyan függvényeket, melyek egy adott osztálytaghoz hozzáférnek, de 
nem szükséges objektumra meghívni azokat, statikus tagfiiggvénynek hívjuk. Tervezzük át 
az osztályt úgy, hogy megőrizzük az alapértelmezett konstruktor-értékek szerepét, de köz- 
ben elkerüljük a globális változó használatának hátrányát: 


class Date f( 
int d, m, y; 
static Date default date; 


bublic: 
Date(int dd -O, int mm -0, int yy -09; 
ÚJ SE 
static void set default(int, int, int); 


J; 


A Date konstruktort immár így határozhatjuk meg: 


Date:: Date(int dd, int mm, int yy) 
( 
d - dd ? dd : default date.d; 
m - mm ? mm : default date.m; 
y 7 yy? yy : default date.y; 


// ellenőrizzük, hogy Date érvényes dátum-e 


J 


Amikor szükséges, módosíthatjuk az alapértelmezett értéket. Egy statikus tagra ugyanúgy 
hivatkozhatunk, mint bármilyen más tagra, sőt, akár egy objektum megnevezése nélkül is; 
ekkor az osztály nevével minősíthetjük: 


void JO 
( 


Date::set default(4, 5, 19459; 


J 


A statikus tagokat — mind az adattagokat, mind a függvényeket — definiálni kell valahol: 


Date Date::default date(16, 12, 17709; 


void Date::set default(int d, int m, int y) 


( 
Date::default. date - Date(d,m,y9; 


j 
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Az alapértelmezett érték itt Beethoven születési dátuma, amíg valaki át nem állítja valami 
másra. Vegyük észre, hogy a Datel jelölés a Date::default date értéket szolgáltatja: 


Date copy of default date — DatoO; 


Következésképpen nincs szükség külön függvényre az alapértelmezett dátum lekérdezéséhez. 
10.2.5. Osztály típusú objektumok másolása 


Alapértelmezés szerint az osztály típusú objektumok másolhatók és kezdőértékként egy 
azonos típusú osztály egy objektumának másolatát is kaphatják, még akkor is, ha konstruk- 
torokat is megadtunk: 


Dated-today; // kezdeti értékadás másolással 


Alapértelmezés szerint az osztály objektum másolata minden tag másolatából áll. Ha nem 
ez a megfelelő viselkedés egy X osztály számára, az X::X(const X£ ) másoló konstruktorral 
megváltoztathatjuk azt. (Erre a §10.4.4.1 pontban részletesebben is visszatérünk.) Ennek 
megfelelően az osztály objektumokat alapértelmezés szerint értékadással is másolhatjuk: 


void KDatek d) 


t 
d - today; 
j 


Az alapértelmezett viselkedés itt is a tagonkénti másolás. Ha ez nem megfelelő egy osztály 
számára, a programozó megadhatja a megfelelő értékadó operátort (410.4.4.1). 


10.2.6. Konstans tagfüggvények 


A Date osztályhoz eddig olyan tagfüggvényeket adtunk, melyek értéket adnak egy Date 
objektumnak vagy megváltoztatják azt, de az érték lekérdezésére sajnos nem adtunk lehe- 
tőséget. Ezen könnyen segíthetünk, ha készítünk néhány függvényt, amelyekkel kiolvas- 
hatjuk az évet, a hónapot és a napot: 


class Date ( 
int d, m, y; 

bublic: 
int dayO const f return d; ) 
int monthO const (f return m; ) 
int yearÓ const; 
ME ves 

Ji 
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Vegyük észre a const minősítőt a függvénydeklarációkban az (üres) paraméterlista után. Ez 
azt jelenti, hogy ezek a függvények nem változtatják meg az objektum állapotát. Termé- 
szetesen a fordítóprogram megakadályozza, hogy véletlenül megszegjük ezt az ígéretet: 


inline int Date::yearO const 


( 


j 


returnyt4; — // hiba: kísérlet tag értékének módosítására konstans függvényben 


Ha egy konstans tagfüggvényt osztályán kívül határozzuk meg, a const utótagot ki kell 


írnunk: 


inline int Date::yearO const // helyes 


( 
return y; 
j 
inline int Date::yearO // hiba: a const minősítő hiányzik a tagfüggvény típusából 
( 
return y; 


j 


Vagyis a const minősítés része a Date::dayO és Date::yearO függvények típusának. 


Egy konstans tagfüggvényt alkalmazhatunk állandó (konstans) és változó (nem konstans) ob- 
jektumokra is, a nem konstans tagfüggvényeket viszont csak nem konstans objektumokra: 


void (Datek d, const Datek cd) 


( 
int i - d.yearO; // rendben 


d.add year(1; // rendben 


int j — cd.yearO; // rendben 
cd.add year(1); // hiba: cd konstans, értéke nem módosítható 


10.2.7. Önhivatkozás 


Az add yearO, add monthO), és add yearÓ állapotfrissítő függvényeket úgy határoztuk 
meg, hogy azok nem adnak vissza értéket. Az ilyen, egymással kapcsolatban levő frissítő 
függvények esetében sokszor hasznos, ha visszaadunk egy, a frissített objektumra mutató 
referenciát, mert a műveleteket ekkor láncba kapcsolhatjuk ( láncolhatjuk"). 
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Tegyük fel, hogy a következőt szeretnénk írni: 


void KDatek d) 


( 
1 7tes 
d.add day(1).add month(1).add year(1); 
Zs 

J 


Ezzel egy napot, egy hónapot és egy évet adunk d-hez. Ehhez viszont minden függvényt 
úgy kell megadnunk, hogy azok egy Date típusú referenciát adjanak vissza: 


class Date f( 


7 ik 

Datekg add yearCGint n); // n év hozzáadása 
Datek add month(int n); /n hónap hozzáadása 
Datek add dayCGint n); // n nap hozzáadása 


Yő 


Minden (nem statikus) tagfüggvény tudja, melyik objektumra hívták meg, így pontosan hi- 
vatkozhat rá: 


Datek Date::add yearCGint n) 


j if (d--29 kk m--2 ££ leapyear(yrn)) f // figyeljünk február 29-re! 
d — 1; 
m — 3; 
j 
3 t- n; 
return "this; 
J 


A "this kifejezés azt az objektumot jelenti, amelyre a tagfüggvényt meghívták. (Egyenérté- 
kű a Simula nyelv 7HIS és a Smalltalk self kifejezésével.) 


Egy nem statikus tagfüggvényben a tAhis kulcsszó egy mutatót jelent arra az objektumra, 
amelyre a függvényt meghívták. Az X osztály egy nem const tagfüggvényében a tAis típusa 
X". Mindazonáltal a tis nem közönséges változó, így nem lehet a címét felhasználni vagy 
értéket adni neki. Az X osztály egy konstans tagfüggvényben a tAis típusa const X" lesz, 
hogy ne lehessen megváltoztatni magát az objektumot (ásd még §5.4.1. 
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A this használata legtöbbször automatikus. Például minden nem statikus tagra való hivatko- 
zás tulajdonképpen a tAis-t használja, hogy a megfelelő objektum tagját érje el. Az add year 
függvényt például egyenértékű, ám fáradságos módon így is megadhattuk volna: 


Datek Date::add year(int n) 


t 
if (this-2d--29 £k£ this-2m--2 ££ leapyear(this-2y:n)) f 
this-2d — 1; 
this-2m — 3; 
) 
this-2y 47 n; 
return "this; 


A this-t meghatározott (explicit) módon gyakran láncolt listák kezelésére használjuk (pél- 
dául §24.3.7.49. 


10.2.7.1. Fizikai és logikai konstansok 


Esetenként előfordulhat, hogy egy tagfüggvény logikailag állandó, mégis meg kell változ- 
tatnia egy tag értékét. A felhasználó számára a függvény nem módosítja az objektum álla- 
potát, de valamilyen, a felhasználó által közvetlenül nem látható részlet megváltozik. 
Az ilyen helyzetet gyakran hívják logikai konstans mivoltnak. A Date osztályt például egy 
függvény visszatérési értéke egy karakterlánccal ábrázolhatja, melyet a felhasználó a kime- 
netben felhasználhat. Egy ilyen ábrázolás felépítése időigényes feladat, ezért érdemes egy 
példányt tárolni belőle, amit az egymást követő lekérdezések mind felhasználhatnak, amíg 
a Date értéke meg nem változik. Ilyen belső gyorsítótár (gyorstár, cache) inkább bonyolul- 
tabb adatszerkezeteknél használatos, de nézzük meg, hogyan működhetne ez a Date osz- 
tály esetében: 


class Date f( 
bool cache valid; 
string cache; 
void compute cache valuecO; // gyorstár feltöltése 
VESS 
bublic: 
e 


string string repO const; // ábrázolás karakterlánccal 
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A felhasználó szemszögéből a string rep függvény nem változtatja meg az objektum álla- 
potát, ezért világos, hogy konstans tagfüggvénynek kell lennie. Másrészt a gyorsítótárat fel 
kell tölteni a használat előtt. Ezt elérhetjük típuskényszerítés alkalmazásával is: 


string Date::string repO const 


f 
if (cache valid -- false) f 
Date: th - const castkDate" (this); // konstans elvetése 
th-:compute cache valuecO; 
th-2cache valid — true; 
J 
return cache; 
J 


Vagyis a const cast operátort (415.4.2.1) használtuk, hogy egy Date" típusú mutatót kap- 
junk a this-re. Ez aligha elegáns megoldás, és nem biztos, hogy egy eredetileg is állandó- 
ként megadott objektum esetében is működik: 


Date d1; 

const Date d2; 

string s1 - d1.string repO; 

string 52 - d2.string repO; // nem meghatározott viselkedés 


A d1 változó esetében a string repO egyszerűen az eredeti típusra alakít vissza, így a dolog 
működik. Ám d2-t konstansként adtuk meg és az adott nyelvi változat esetleg valamilyen 
memória-védelmet alkalmaz az állandó értékek megőrzésére. Ezért a d2.string repO hívás 
nem biztos, hogy pontosan meghatározható, az adott nyelvi változattól független ered- 
ménnyel fog járni. 


10.2.7.2. A mutable minősítő 


Az előbb leírt típuskényszerítés (a const minősítő átalakítása) és a vele járó, megvalósítástól 
függő viselkedés elkerülhető, ha a gyorsítótárba kerülő adatokat , változékony"7-ként 
(mutable) adjuk meg: 


class Date f( 
mutable bool cache valid; 
mutabte string cache; 


void compute cache valueO const; // (változékony) gyorstár feltöltése 
KÉS 
bublic: 
Joás 
string string repO const; // ábrázolás karakterlánccal 


4 
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A mutable tárolási minősítés azt jelenti, hogy a tagot úgy kell tárolni, hogy akkor is módo- 
sítható legyen, ha konstans objektum. Vagyis a mutable azt jelenti, hogy ,soha nem állan- 


dó". Ezt felhasználva egyszerűsíthetünk a síring repO meghatározásán: 


string Date::string repO const 
t 
if (cache valid) f 
compute cache valueO); 
cache valid — true; 


J 


return cache; 


J 


Ezáltal a string repO-et megfelelően használatba vehetjük: 


Date d3; 

const Date dá; 

string s3 - d3.string repO; 

string s4 - dá.string repO; // rendben! 


A tagok változékonyként való megadása akkor alkalmas leginkább, ha az ábrázolásnak csak 
egy része változhat. Ha az objektum logikailag változatlan marad, de a tagok többsége mó- 
dosulhat, jobb a változó adatrészt külön objektumba tenni és közvetett úton elérni. Ezzel 
a módszerrel a gyorsítótárba helyezett karakterláncot tartalmazó program így írható meg: 


struct cache ( 
bool valid; 
string rep; 
2. 
J; 


class Date f( 


cache" c; // kezdeti értékadás a konstruktorban (§10.4.6) 
void compute cache valueO const; // a gyorstár által mutatott elem feltöltése 
Ms 

bublic: 
Mas 
string string repO const; // ábrázolás karakterlánccal 


J; 


string Date::string repO const 
( 
if (c-:valid) f 
compute cache valueO; 
c-svalid — true; 


J 


return c-2rep; 
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A gyorsítótárat támogató eljárások az ún. ,lusta" vagy takaros kiértékelés (lazy evaluation) 
különféle formáira is átvihetők. 


10.2.8. Struktúrák és osztályok 


Definíció szerint a struktúra (struct), olyan osztály, melynek tagjai alapértelmezés szerint 
nyilvánosak. Vagyis a 


struct s f ... 
egyszerűen rövidítése az alábbinak: 
class s f public: ... 


A private: elérhetőségi minősítés annak jelzésére használható, hogy a következő tagok pri- 
vát elérésűek, a public: pedig azt mondja, hogy a következő tagok nyilvánosak. Attól elte- 
kintve, hogy a nevek különböznek, az alábbi deklarációk egyenértékűek: 


class Date1 ( 
int d, m, y; 
bublic: 
DatelICGint dd, int mm, int yy); 


void add yearGint n); // n év hozzáadása 


5 


struct Date2 ( 
Private: 
int d, m, y; 
bublic: 
Date2(int dd, int mm, int yy); 


void add yearCGint n); // n év hozzáadása 


3 


A választott stílust csak a körülmények és az egyéni ízlés határozza meg. Én általában 
azokat az osztályokat adom meg struct-ként, amelyekben minden tag nyilvános. Ezekre az 
osztályokra úgy gondolok, mint amik nem igazi típusok, csak adatszerkezetek. A kon- 
struktorok és lekérdező függvények nagyon hasznosak lehetnek a struktúrák számára is, de 
inkább csak jelölésbeli könnyebbséget jelentenek, mintsem a típus tulajdonságait garantál- 
ják (mint az invariánsok, lásd §24.3.7.1. 
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Az osztályokban nem szükséges először az adattagokat megadni, sőt, sokszor jobb azokat 
a deklaráció végére tenni, hogy kihangsúlyozzuk a nyilvános felhasználói felületet alkotó 
függvényeket: 


class Date3 ( 
bublic: 
Date3(int dd, int mm, int yy); 


void add yearCGint n); // n év hozzáadása 
brivate: 
int d, m, y; 


J; 


Valódi kódban, ahol általában mind a nyilvános felület, mind a tényleges megvalósítás terje- 
delmesebb, mint a tankönyvi példákban, rendszerint a Date3 stílusát részesítem előnyben. 


Az elérhetőségi minősítéseket az osztálydeklarációkon belül többször is használhatjuk: 


class Date4 ( 
bublic: 
Dateá(Gint dd, int mm, int yy); 
brivate: 
int d, m, y; 
bublic: 
void add yearCGint n); /n év hozzáadása 


J; 


Ha azonban a deklaráció több nyilvános részt is tartalmaz (mint a Date4 osztálynál), akkor 
a kód zavarossá válhat. Több privát rész használata szintén ezt eredményezi. Mindazonál- 
tal a számítógép által elkészített kódok számára kedvező, hogy az elérhetőségi minősítések 
ismétlődhetnek. 


10.2.9. Osztályon belüli függvénydefiníciók 


Az osztályon belül definiált (nem csak deklarál9) függvények helyben kifejtett (inline) tag- 
függvénynek számítanak, azaz a fordítóprogram a függvény meghívása helyett közvetlenül 
beilleszti a kódot. Vagyis az osztály meghatározásán belüli kifejtés kicsi, de gyakran hasz- 
nált függvények számára hasznos. Ahhoz az osztály-definicióhoz hasonlóan, amelyben sze- 
repel, az osztályon belül kifejtett függvény is szerepelhet több fordítási egységben (az 
$include utasítással beépítve). Persze az osztályhoz hasonlóan jelentésének minden fel- 
használásakor azonosnak kell lennie (49.2.3). 
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Az a stílus, mely szerint az adattagokat az osztály definiciójának végére helyezzük, kisebb 
gondhoz vezet az adatábrázolást felhasználó nyilvános , inline" függvények tekintetében. 
Vegyük ezt a példát: 


class Date ( // zavaró lehet 
public: 
int dayO const f return d; ) // return Date::d 
KÉS 
brivate: 
int d, m, y; 


ő 


Ez szabályos C-4--kód, mivel egy osztály egy tagfüggvénye az osztály minden tagjára hivat- 
kozhat, mintha az osztály definiciója már a tagfüggvény-törzsek beolvasása előtt teljes lett 
volna. A kódot olvasó programozót azonban ez megzavarhatja, ezért én vagy előreveszem 
az adatokat, vagy az , inline" tagfüggvényeket az osztály után fejtem ki: 


class Date f( 
bublic: 
int dayO const; 
MI si 
brivate: 
int d, m, y; 


J8 


inline int Date::dayO const f return d; ) 


10.3. Hatékony felhasználói típusok 


Az előző Date osztály példáján bemutattuk az osztályok meghatározásához szükséges alap- 
vető nyelvi elemeket. Most az egyszerű és hatékony tervezésre helyezzük a hangsúlyt és azt 
mutatjuk be, hogy az egyes nyelvi elemek hogyan támogatják ezt. 


Számos program használ egyszerű, de sűrűn előforduló elvont fogalmakat, konkrét típu- 
sokkal ábrázolva: latin vagy kínai karaktereket, lebegőpontos számokat, komplex szá- 
mokat, pontokat, mutatókat, koordinátákat, (mutató-eltolás Coffset)) párokat, dátumokat, 
időpontokat, értékkészleteket, kapcsolatokat, csomópontokat, (érték-egység) párokat, le- 
mezcímeket, forráskód-helyeket, BCD karaktereket, pénznemeket, vonalakat, téglalapokat, 
rögzített pontos számokat, törtrésszel bíró számokat, karakterláncokat, vektorokat és töm- 
böket. Gyakran előfordul, hogy egy program közvetetten támaszkodik ezen típusok né- 
melyikére és még többre közvetlenül, könyvtárak közvetítésével. 
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A C4t4 más programozási nyelvekkel egyetemben közvetlenül támogat néhányat a fenti tí- 
pusok közül, ám számuk miatt nem lehetséges az összeset közvetlenül támogatni. Egy álta- 
lános célú programozási nyelv tervezője nem is láthatja előre az egyes alkalmazások igé- 
nyeit. Tehát szükség van olyan eljárásokra, melyekkel a felhasználó adott célú típusokat 
adhat meg. Az ilyen típusokat konkrét típusoknak vagy konkrét osztályoknak hívjuk, hogy 
megkülönböztessük őket az absztrakt (elvonD) osztályoktól (412.3), illetve az osztályhierar- 
chiák osztályaitól (412.2.4 és §12.4). 


A C44 nyelv egyik kifejezett célja volt, hogy az ilyen felhasználói típusok megadását és ha- 
tékony használatát is támogassa, mert ezek az , elegáns" programozás alapkövei. Mint álta- 
lában, itt is érvényes, hogy az egyszerű és földhözragadt sokkal jelentősebb, mint a bonyo- 
lult és körmönfont. 


Ennek fényében készítsünk egy jobb dátumosztályt: 


class Date f 
public: // nyilvános felület 
enum Monith f jan-1, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec ); 


class Bad date f );; // kivételosztály 
Date(int dd -O, Month mm -Month(0), int yy -0); — // 0 jelentése "vedd az 
// alapértelmezettet" 

// függvények a Date vizsgálatához 

int dayO const; 

Month monthO const; 

int yearO const; 

string string repO const; // ábrázolás karakterlánccal 

void char. rep(char s[ J) const; // ábrázolás C stílusú karakterlánccal 

static void set default(int, Month, int); 
// függvények a Date módosításához 

Datek add year(int n); // n év hozzáadása 

Datek add montl(int n); // n hónap hozzáadása 

Date add dayCdint n); // n nap hozzáadása 
brivate: 

int d, m, y; // ábrázolás 


static Date default date; 
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A végezhető műveletek ilyen halmaza meglehetősen jellemző a felhasználói adattípusokra. 
A következők szerepelnek benne: 


1. Egy konstruktor, amely kezdőértéket ad az objektumoknak és változóknak 

2. Lekérdező függvények, melyekkel egy Date-et megvizsgálhatunk. Ezek const 
minősítése jelzi, hogy nem módosítják annak az objektumnak vagy változónak 
az állapotát, amelyre meghívták őket. 

3. A Date objektumokat és változókat kezelő függvények, melyek az ábrázolás 
vagy a konkrét megvalósítás ismerete, illetve az egyes elemek szerepével való 
bajlódás nélkül is meghívhatók. 

4. Automatikusan definiált műveletek, melyek segítségével a Date-ek szabadon 
másolhatók. 

5. A Bad date osztály, mellyel a hibák mint kivételek jelezhetők. 


A Month (hónap) típust azért vezettem be, hogy kezeljem azt a problémát, amit az okoz, 
hogy emlékeznünk kell rá: vajon június 7-ét amerikai stílusban Date(6, 79-nek vagy európai 
stílusban Date(7, 69-nak kell-e írnunk. Az alapértelmezett paraméter-értékek kezelésére is 
gondoltam, ezzel külön eljárás foglalkozik. 


Gondolkodtam azon, hogy a napok és évek ábrázolására a Day-t és a Year-t, mint önálló tí- 
pusokat bevezessem, hogy a Date(1995 jul, 27) és a Date(27 jul, 1995) összekeveredésé- 
nek veszélyét elkerüljem. Ezek a típusok azonban nem lennének annyira hasznosak, mint 
a Month. Majdnem minden ilyen hiba amúgy is kiderül futási időben — nemigen dolgozom 
olyan dátumokkal, mint a 27-ik év július 26-ika. Az 1800 előtti történelmi dátumok kezelé- 
se annyira bonyolult, hogy jobb történész szakértőkre bízni. Ezenkívül pedig egy 
, valahanyadikát" nem lehet rendesen ellenőrizni a hónap és az év ismerete nélkül. (Egy al- 
kalmas Yeartípus meghatározására nézve lásd: §11.7.1.) 


Az alapértelmezett dátumot mint érvényes Date objektumot definiálni kell valahol: 


Date Date::default date(22 jan, 1901; 


A §10.2.7.1-ben említett gyorsítótáras (cache) módszer egy ilyen egyszerű típusnál felesle- 
ges, így kihagytam. Ha mégis szükséges, kiegészíthetjük vele az osztályt, mint a felhaszná- 
lói felületet nem érintő megvalósítási részlettel. 
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Íme egy kicsi elméleti példa arra, hogy lehet Date-eket használni: 


void fDatek d) 


( 
Date Ilvb day - Date(16, Date::dec,d.yearO ); 


if (d.dayO--29 £k d.monthO--Date::feb) ( 
7 téső 


J 


if (midnightO) d.add day(1; 


cout c£ "A következő nap:" c£ d41 cz Mi; 


Feltételezzük, hogy a cc kimeneti és a 4£ összeadó művelet a Date-ekre definiált; (ezt 
a §10.3.3-ban valóban meg is tesszük). 


Figyeljük meg a Date::feb jelölést. Az 0 nem tagfüggvénye Date-nek, így meg kell adni, 


hogy a Date-nek és nem valami másnak a feb-jéről van szó. 


Miért éri meg egy külön típust megadni egy olyan egyszerű dolog számára, mint egy dátum? 
Végül is beérhetnénk egy egyszerű adatszerkezettel... 


struct Date ( 


int day, month, year; 


J; 


...és hagynánk, hogy a programozók döntsék el, mit csinálnak vele. De ha ezt tennénk, ak- 
kor minden felhasználónak magának kellene a Date-ek összetevőit kezelnie: vagy közvet- 
lenül, vagy külön függvényekben. Ez pedig azzal járna, hogy a dátum fogalma , szétszó- 
ródna", így azt nehezebb lenne megérteni, dokumentálni és módosítani. Ha egy fogalmat 
egyszerű adatszerkezetként bocsátunk a felhasználók rendelkezésére, az szükségszerűen 
külön munkát igényel tőlük. 


Ezenkívül bár a Date típus látszólag egyszerű, mégis gondot igényel úgy megírni, hogy he- 
lyesen működjék. Például egy Date objektum növeléséhez szökőévekkel kell törődni, azzal 
a ténnyel, hogy a hónapok különböző hosszúságúak és így tovább (ásd a §10.6[1]-es fel- 
adatot). Az év-hónap-nap adatábrázolás ráadásul sok program számára szegényes. Ha vi- 
szont úgy döntünk, hogy megváltoztatjuk, csak a kijelölt függvényeket kell módosítanunk. 
Ha a Date-et például az 1970. január elseje utáni vagy előtti napok számával akarnánk áb- 
rázolni, csak a Date tagfüggvényeit kellene megváltoztatnunk (§10.6.[2D. 
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10.3.1. Tagfüggvények 


Természetesen minden tagfüggvényt ki kell fejteni valahol. Íme a Date konstruktorának 
definíciója: 


Date:: Date(int dd, Month mm, int yy) 


f 
if (yy -— 0) yy - default date.yearO; 
if (nm -- 0) mm - default date.monthO; 
if (dd -- 0) dd - default date.dayO; 
int max; 
switch (mm) f 
case feb: 
max - 28-leapyear(yy); 
break; 
case apr: case jun: case sep: case nov: 
max - 30; 
break; 
case jan: case mar: case may: case jul: case aug: case oct: case dec: 
max - 31; 
break; 
default: 
throw Bad dateO; // valaki csalt 
vő 
if (ddcS1 I I maxzdd) throw Bad dateO; 
B élné Za 
m - mm; 
d - dd; 
J 


A konstruktor ellenőrzi, hogy a kapott adatok érvényes dátumot adnak-e. Ha nem, mint 
például a Date(30, Date:: Feb, 1994) esetében, kivételt vált ki (48.3, 14. fejezeb, amely jelzi, 
hogy olyan jellegű hiba történt, amit nem lehet figyelmen kívül hagyni. Ha a kapott adatok 
elfogadhatóak, a kezdeti értékadás megtörténik. Ez meglehetősen jellemző eljárásmód. 
Másfelől ha a Date objektum már létrejött, akkor az további ellenőrzés nélkül felhasználha- 
tó és másolható. Más szóval a konstruktor felállítja az osztályra jellemző invariánst (ebben 
az esetben azt, hogy egy érvényes dátumról van szó). A többi tagfüggvény számíthat erre 
az állapotra és kötelessége fenntartani azt. Ez a tervezési módszer óriási mértékben leegy- 


szerűsítheti a kódot (ásd a 24.3.7.1-es ponto. 
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A Month(0) értéket (amely nem jelent igazi hónapo0) a , vegyük az alapértelmezett hóna- 
pot" jelzésére használjuk. A Month felsorolásban megadhatnánk egy értéket kifejezetten en- 
nek jelzésére, de jobb egy nyilvánvalóan érvénytelen értéket használni erre a célra, mint 
hogy olyan látszatot keltsünk, hogy 13 hónap van egy évben. Vegyük észre, hogy a O érté- 
ket azért használhatjuk, mert az a MonitA felsorolás biztosított garantált értéktartományba 
esik (44.38). 


Gondolkodtam azon, hogy az adatellenőrzést külön, egy is date0 függvénybe teszem, de 
ez olyan kódhoz vezetne, amely bonyolultabb és kevésbé hatékony, mint a kivételek elka- 
pásán alapuló. Tegyük fel például, hogy a 22 művelet értelmezett a Date osztályra: 


void fillrvectorZDatez£ aa) 
( 
while (cin) f 
Date d; 
try ( 
cin 55 d; 


J 


catch (Date::Bad date) ( 
// saját hibakezelő 


continue; 
? 


J 
aa.push back(d); // lásd §3.7.3 


Mint az ilyen egyszerű konkrét osztályok esetében szokásos, a tagfüggvények meghatáro- 
zása a triviális és a nem túl bonyolult között mozog. Például: 


inline int Date::dayO const 


( 


return d; 
2 


J 
Datek Date::add month(int n) 
( 


if (1-0) return "this; 


if (120) ( 
int delta y - n/12; 
int mm - mtn9012; 
if (12 c mm) f // megjegyzés: int(dec)--12 
delta y4t; 
mm -- 12; 
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// most azok az esetek jönnek, amikor Month(mm)J-nek nincs d napja 


y 47 delta y; 
m - Month(mm); 
return "this; 


J 
// negatív n kezelése 


return "this; 


10.3.2. Segédfüggvények 


Egy osztályhoz általában számos olyan függvény tartozhat, melyeket nem szükséges magá- 
ban az osztályban tagként megadni, mert nincs szükségük a belső adatábrázolás közvetlen 
elérésére: 


int diff(Date a, Date b); // napok száma az [a,b] vagy [b,aJ tartományban 
bool leapyearGint y); 

Date next weekday(Date d); 

Date next saturday(Date d); 


Ha ezeket a függvényeket magában az osztályban fejtenénk ki, az bonyolultabbá tenné az 
osztály felületét és a belső adatábrázolás esetleges módosításakor több függvényt kellene 
ellenőrizni. 


Hogyan kapcsolódnak az ilyen segédfüggvények a Date osztályhoz? Hagyományosan 
a deklarációjukat az osztály deklarációjával azonos fájlba tennénk, így azon felhasználók 
számára, akiknek szükségük van a Date osztályra, rögtön ezek is rendelkezésre állnának 
a felületet leíró fejállomány beépítése után (49.2.1D: 


$include "Date.h" 
A Date.h fejállomány használata mellett vagy helyett a segédfüggvények és az osztály kap- 


csolatát úgy tehetjük nyilvánvalóvá, hogy az osztályt és segédfüggvényeit egy névtérbe fog- 
laljuk (48.29: 


namespace Chrono f // dátumkezelő szolgáltatások 
class Date f/? ... "9; 


int diff((Date a, Date b); 
bool leapyearGint y); 
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Date next weekday(Date d); 
Date next saturday(Date d); 
Ve 


j 


A Chrono névtér természetesen a többi kapcsolódó osztályt is tartalmazná, például a Time 
(Idő) és Stopwatch (Stopper) osztályokat és azok segédfüggvényeit is. Egy egyetlen osztályt 
tartalmazó névtér használata általában csak túlbonyolított, kényelmetlen kódhoz vezet. 


10.3.3. Operátorok túlterhelése 


Gyakran hasznos lehet olyan függvényeket felvenni, amelyek a hagyományos jelölésmód 
használatát biztosítják. Az operator-- függvény például lehetővé teszi az -—— egyenlőségi 
operátor használatát a Date objektumokra: 


inline bool operator-—(Date a, Date b) // egyenlőség 


( 
return a.dayO--b.dayO k£ a.monthO--b.monthO ké a.yearO0--b.yearO; 


J 


Egyéb kézenfekvő jelöltek: 


bool operator!1-(Date, Date); // egyenlőtlenség 

bool operator£(Date, Date); // kisebb 

bool operatorx(Date, Date); // nagyobb 

VESS 

Datek operatort4(Datek d); // Date növelése egy nappal 
Datek operator--(Dateg d); // Date csökkentése egy nappal 
Datek operatort—-(Datek d, int n); // n nap hozzáadása 
Datek operator-(Datek d, int n); // n nap kivonása 

Date operator4 (Date d, int n); /n nap hozzáadása 

Date operator-(Date d, int n); // n nap kivonása 
ostreamk operatorzz(ostreamk, Date d); // d kiírása 

istreamk operator::(istreamfk, Datek d); // beolvasás d-be 


A Date osztály számára ezen operátorok használhatósága pusztán kényelmi szempontnak 
tűnik. Ám sok típus — például a komplex számok (§11.3), a vektorok (§3.7.1) és a függ- 
vényszerű objektumok (418.4) — esetében ezek használata annyira beidegződött a felhasz- 
nálóknál, hogy szinte kötelező megadni őket. Az operátorok túlterhelésével a 11. fejezet 
foglalkozik. 
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10.3.4. A konkrét osztályok jelentősége 


Azért hívjuk a Date és más egyszerű felhasználói típusokat konkrét típusoknak, hogy meg- 
különböztessem azokat az absztrakt osztályoktól (42.5.4) és az osztályhierarchiáktól (12.39, 
illetve hogy hangsúlyozzam az olyan beépített típusokkal való hasonlóságukat, mint az int 
vagy a float. Ezeket értéktípusoknak (value types) is nevezik, használatukat pedig ér- 
tékközpontű programozásnak (value-oriented programming). Használati modelljük és mö- 
götte levő , filozófia" nagyon különbözik attól, amit gyakran objektum-orientált programo- 
zásnak hívnak (§2.6.2). 


A konkrét osztályok dolga az, hogy egyetlen, viszonylag egyszerű dolgot jól és hatékonyan 
csináljanak. Általában nem cél, hogy a felhasználónak eszközt adjunk a kezébe egy konk- 
rét osztály viselkedésének megváltoztatására. Így a konkrét osztályokat nem szánjuk arra 
sem, hogy többalakú (polimorf) viselkedést tanúsítsanak (42.5.5, §12.2.69. 


Ha nem tetszik egy konkrét típus viselkedése, akkor írhatunk egy másikat, ami a kívánal- 
maknak megfelelően működik. Ez az adott típus , újrahasznosításával" is elérhetjük; a típust 
pontosan úgy használhatjuk fel az új típus megvalósításához, mint egy int-et: 


class Date and time ( 
Private: 
Date d; 
Time t; 
bublic: 
Date and time(Date d, Time 19; 
Date and time(int d, Date::Month m, int y, Time 0; 
I en 
J; 


A 12. fejezetben tárgyalt öröklődési eljárást úgy használhatjuk fel egy új típus meghatározá- 
sára, hogy csak az eltéréseket kell leírnunk. A Vec osztályt például a vector alapján készít- 
hetjük el (§3.7.29. 


Egy valamirevaló fordítóprogrammal egy, a Date-hez hasonló konkrét osztály használata 
nem jár a szükséges tárolóhely vagy a futási idő rejtett növekedésével. A konkrét osztályok 
mérete fordítási időben ismert, ezért az objektumok számára helyet foglalhatunk a futási 
veremben is, azaz a szabad tárat érintő műveletek nélkül. A memóriakiosztás is ismert, így 
a helyben fordítás egyszerű feladat. A memóriakiosztásnak más nyelvekkel, például a C-vel 
vagy a Fortrannal való összeegyeztetése is hasonlóan könnyen, külön erőfeszítés nélkül 
megoldható. 
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Az ilyen egyszerű típusok megfelelő halmaza teljes programok alapjául szolgálhat. Ha egy 
alkalmazásban nincsenek meg a megfelelő kicsi, de hatékony típusok, akkor a túl általános 
és , költséges" osztályok használata komoly futási időbeli és tárfelhasználás-beli pazarlás- 
hoz vezethet. A konkrét típusok hiánya másfelől zavaros programokat eredményez, illetve 


azt, hogy minden programozó megírja az ,egyszerű és sűrűn használt" adatszerkezeteket 
közvetlenül kezelő kódot. 


10.4. Objektumok 


Objektumok többféleképpen jöhetnek létre: lehetnek automatikus vagy globális változók, 
osztályok tagjai stb. Az alábbiakban ezeket a lehetőségeket, a rájuk vonatkozó szabályokat, 


az objektumok kezdőállapotát beállító konstruktorokat és a használatból kikerülő objektu- 
mok , eltakarítására" szolgáló destruktorokat tárgyaljuk. 


10.4.1. Destruktorok 

Az objektumok kezdőállapotát a konstruktorok állítják be, vagyis a konstruktorok hozzák 
létre azt a környezetet, amelyben a tagfüggvények működnek. Esetenként az ilyen környe- 
zet létrehozása valamilyen erőforrás — fájl, zár, memóriaterület — lefoglalásával jár, amit 
a használat után fel kell szabadítani (§414.4.79. Következésképpen némelyik osztálynak 
szüksége van egy olyan függvényre, amely biztosan meghívódik, amikor egy objektum 
megsemmisül, hasonlóan ahhoz, ahogy a konstruktor meghívására is biztosan sor kerül, 
amikor egy objektum létrejön: ezek a destruktor (megsemmisítő, destructor) függvények. 
Feladatuk általában a rendbetétel és az erőforrások felszabadítása. A destruktorok automa- 
tikusan meghívódnak, amikor egy automatikus változót tartalmazó blokk lefut, egy dinami- 
kusan létrehozott objektumot törölnek és így tovább. Nagyon különleges esetben van csak 
szükség arra, hogy a programozó kifejezetten meghívja a destruktort (410.4.11). 


A destruktor legjellemzőbb feladata, hogy felszabadítsa a konstruktorban lefoglalt memó- 
riaterületet. Vegyünk például egy valamilyen Name típusú elemek táblázatát tartalmazó 
Table osztályt. A konstruktornak le kell foglalnia az elemek tárolásához szükséges memó- 
riát. Ha a Table objektum bármilyen módon törlődik, a memóriát fel kell szabadítani, hogy 
máshol fel lehessen majd használni. Ezt úgy érhetjük el, hogy megírjuk a konstruktort ki- 
egészítő függvényt: 


class Name f 
const char"? s; 


f/40ee 


Jo 
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class Table f 


Name" p; 
size tsz; 
bublic: 
Tablecsize ts - 15) ( b - new Namelsz — s]; ) // konstruktor 
-Table0 f delete[ ] p; ) // destruktor 


Name" lookupíconst char ?); 
bool insert(rName"); 


); 


A destruktort jelentő -7ableO jelölés a komplemensképzést jelölő - szimbólumot használ- 
va utal a destruktornak a 7ableO konstruktorhoz való viszonyára. Az összetartozó kon- 
struktor-destruktor pár meghatározása a C-t--ban szokásos eljárás változó méretű objek- 
tumok megvalósítására. A standard könyvtár tárolói, például a map, ennek a módszernek 
valamelyik változatát használják, hogy az elemeik számára tárolóhelyet biztosítsanak, ezért 
a programozó a következőkben leírtakra támaszkodik, amikor valamelyik standard könyv- 
tárbeli tárolót használja (Így viselkedik például a szabványos siring osztály is.) A leírtak al- 
kalmazhatóak a destruktor nélküli osztályokra is. Ezekre úgy tekinthetünk, mint amelyek- 
nél egy olyan destruktorunk van, amely nem csinál semmit. 


10.4.2. Alapértelmezett konstruktorok 


Hasonlóképpen a legtöbb típust úgy tekinthetjük, mint amelynek van alapértelmezett 
konstruktora. Az alapértelmezett konstruktor az, amelyiket paraméter nélkül hívhatjuk 
meg. Minthogy a fenti példában a 15 mint alapértelmezett érték adott, a 7able:: Table(size 1) 
függvény alapértelmezett konstruktor. Ha a programozó megadott alapértelmezett 
konstruktort, akkor a fordítóprogram azt fogja használni, máskülönben szükség esetén 
megpróbál létrehozni egyet. A fordítóprogram által létrehozott alapértelmezett konstruktor 
automatikusan meghívja az osztály típusú tagok és a bázisosztályok (412.2.2) alapértelme- 
zett konstruktorát: 


struct Tables ( 
int í; 
int vif10]; 
Table t1; 
Table vt(10]; 


vő 


Tables tt; 
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Itt tt kezdőértékkel való feltöltése fordítás közben létrehozott alapértelmezett konstruktor 
segítségével történik, amely a Table(159-öt hívja meg tt.t1-re és tt.vt minden egyes elemé- 
re. Másrészt tt.i és tt.vi elemei nem kapnak kezdőértéket, mert ezek az objektumok nem 
osztály típusúak. Az osztályok és a beépített típusok egymástól eltérő kezelésmódjának a C- 
vel való egyeztetés és a futási idő növelésétől való tartózkodás az oka. 

Mivel a const-ok és a referenciák kötelezően kezdőértéket kell, hogy kapjanak (§5.5, 45.49, 
az ilyeneket tartalmazó tagoknak nem lehet alapértelmezett konstruktora, hacsak a progra- 


mozó kifejezetten nem gondoskodik konstruktorról (410.4.6.1: 


struct X ( 
const int a; 


const inik Tr; 


J; 


XX; 


§ 


// hiba: nincs alapértelmezett konstruktor X számára 


Az alapértelmezett konstruktorok közvetlen módon is hívhatók (410.4.10). A beépített típu- 
soknak szintén van alapértelmezett konstruktoruk (46.2.8). 


10.4.3. Létrehozás és megsemmisítés 
Tekintsük át a különböző módokat: hogyan hozhatunk létre objektumot és később az ho- 
gyan semmisül meg. Objektum a következő módokon hozható létre: 


§10.4.4 — Névvel ellátott automatikus objektumként, amely akkor keletkezik, ami- 
kor a program végrehajtása során deklarációja kiértékelődik, és akkor 
semmisül meg, amikor a program kilép abból a blokkból, amelyen belül 
a deklaráció szerepelt. 

§10.4.5 — Szabad tárbeli objektumként, amely a new operátor használatával jön lét- 
re és a delete operátor használatával semmisül meg. 

§10.4.6 Nem statikus tagobjektumként, amely egy másik osztály objektum tagja- 
ként jön létre és azzal együtt keletkezik, illetve semmisül meg. 

§10.4.7  — Tömbelemként, amely akkor keletkezik és semmisül meg, amikor 
a tömb, melynek eleme. 

§10.4.3 — Lokális statikus objektumként, amely akkor jön létre, amikor a program 
végrehajtása során először találkozik a deklarációjával és egyszer semmi- 
sül meg: a program befejezésekor. 

§10.4.9 Globális, névtérbeli vagy statikus osztály-objektumként, amely egyszer, 

a program indulásakor jön létre és a program befejezésekor semmisül meg. 
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§10.4.10 Ideiglenes objektumként, amely egy kifejezés kiértékelésekor jön létre és 
a teljes kifejezés végén, melyben előfordult, semmisül meg. 

§10.4.11 Felhasználó által írt függvénnyel végzett, paraméterekkel vezérelt lefog- 
lalási művelet segítségével nyert, a memóriába helyezett objektumként. 

§10.4.12 Unió tagjaként, amelynek nem lehet sem konstruktora, sem destruktora. 


Ez a felsorolás nagyjából a fontosság sorrendjében készült. A következő alpontokban rész- 
letesen elmagyarázzuk az objektumok létrehozásának ezen változatait és használatukat. 


10.4.4. Lokális változók 


A lokális változók konstruktora minden alkalommal végrehajtódik, valahányszor a vezérlés 
fonala , keresztülhalad" a változó deklarációján, a destruktor végrehajtására pedig akkor ke- 
rül sor, amikor kilépünk a változó blokkjából. A lokális változók destruktorai konstruk- 
toraik sorrendjéhez viszonyítva fordított sorrendben hajtódnak végre: 


void f(int i) 
f 
Table aa; 
Table bb; 
if (120) ( 
Table cc; 
Jaa 
j 
Table dd; 
VÁZAT 
J 


Itt aa, bb és dd ebben a sorrendben keletkeznek az /0 meghívásakor és a dd, bb, aa sor- 
rendben semmisülnek meg, amikor a vezérlés kilép az /0-ből. Ha egy hívásnál i:0, a cc 
a bb után jön létre, és dd létrejötte előtt semmisül meg. 


10.4.4.1. Objektumok másolása 


Ha t1 és t2 a Table osztályba tartozó objektumok, 12-t1 alapértelmezés szerint t7-nek ta- 
gonkénti átmásolását jelenti 72-be (410.2.59. Ha nem bíráljuk felül ezt az alapértelmezett vi- 
selkedést, meglepő (és rendszerint nemkívánatos) hatás léphet fel, ha olyan osztály objek- 
tumaira alkalmazzuk, melynek mutató tagjai vannak. A tagonkénti másolás rendszerint nem 
megfelelő olyan objektumok számára, amelyek egy konstruktor-destruktor pár által kezelt 
erőforrásokat tartalmaznak: 
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void hO 
t 
Table t1; 
Table 12 — t1; // kezdeti értékadás másolással: problémás 
Table 13; 
t3 — 12: // értékadás másolással: problémás 


Itt a 7able alapértelmezett konstruktora kétszer hívódik meg: egyszer t1-re és egyszer 13-ra. 
A t2-rre nem hívódik meg, mert ez a változó a 271-ből való másolással kapott kezdőértéket. 
A Table destruktor viszont háromszor hívódik meg: t7-re, t2-re és 13-ra is. Alapértelmezés sze- 
rint az értékadás tagonkénti másolást jelent, így a 10 függvény végén £t7, t2 és 13 mindegyike 
arra a névtömbre hivatkozó mutatót fogja tartalmazni, amely t7 létrejöttekor kapott helyet 
a szabad tárban. A mutató, mely a £3 létrejöttekor kijelölt névtömbre mutat, nem marad meg, 
mert a 13-12 értékadás következtében felülíródik, így az általa elfoglalt tárterület a program 
számára örökre elvész, hacsak nincs automatikus szemétgyűjtés (410.4.5). Másrészt a t7 részé- 
re létrehozott tömb t1-ben, 12-ben és 13-ban egyaránt megjelenik, tehát háromszor is törlődik. 
Ez nem meghatározott és valószínűleg katasztrofális eredményhez vezet. 


Az ilyen anomáliák elkerülhetők, ha megadjuk, mit jelent egy 7able objektum másolása: 


class Table ( 


VAR 
Table(const Tableg ); // másoló konstruktor 
Tablek operator—(const Table ); // másoló értékadás 


J; 
A programozó bármilyen alkalmas jelentést meghatározhat ezen másoló műveletek számá- 
ra, de az ilyen típusú tárolók esetében a másoló művelet hagyományos feladata az, hogy le- 
másolja a tartalmazott elemeket (vagy legalábbis a felhasználó számára úgy tesz, mintha ez 
a másolás megtörtént volna, lásd §11.129: 


Table:: Table(const Tablekg t) // másoló konstruktor 
( 

b - new Namelsz-zt. szt; 

for (int i - O; issz; 1734) pliJ — t.plil; 


J 


Table Table::oberator—(const Tablek b) // értékadás 
( 


if (this !- kD ( // óvakodjunk az ön-értékadástól: t — t 
delete[ ] p; 
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b - new Namelszzt.szl; 
for Gnt i — O; issz; ix) pliJ — t.plij; 
J 


return "this; 


Mint majdnem mindig, a másoló konstruktor és az értékadó művelet itt is jelentősen eltér. 
Ennek alapvető oka az, hogy a másoló konstruktor le nem foglalt memóriát készít fel a fel- 
használásra, míg az értékadó műveletnek egy már létrehozott objektumot kell helyesen 
kezelnie. 


Az értékadást bizonyos esetekben optimalizálni lehet, de az értékadó operátor általános 
célja egyszerű: védekezni kell a saját magával való értékadás ellen, törölni kell a régi ele- 
meket, előkészíteni és bemásolni az új elemeket. Általában minden nem statikus tagot má- 
solni kell (410.4.6.3.) 


10.4.5. A szabad tár 


A dinamikusan kezelt memóriaterületen, a szabad tárban létrehozott objektumok kon- 
struktorát a new operátor hívja meg, és ezek az objektumok addig léteznek, amíg a rájuk 
hivatkozó mutatóra nem alkalmazzuk a delete operátort: 


int mainŐ 


( 
Table? p - new Table; 


Table? g - new Table; 


delete p; 
delete p; // valószínűleg futási idejű hibát okoz 


A Table::Table0 konstruktort kétszer hívjuk meg, csakúgy, mint a 7able::-TableO 
destruktort. Sajnos azonban ebben a példában a new-k és delete-ek nem felelnek meg egy- 
másnak: a p által hivatkozott objektumot kétszer töröltük, míg a g által mutatottat egyszer 
sem. Nyelvi szempontból egy objektum nem törlése nem hiba, mindössze a memória pa- 
zarlása, mindazonáltal egy hosszan futó programnál az ilyen , memóriaszivárgás" vagy ,me- 
mórialyuk" (memory leak) súlyos és nehezen felderíthető hiba. Szerencsére léteznek az 
ilyesfajta memóriaszivárgást kereső eszközök is. A b által mutatott objektum kétszeri törlé- 
se súlyos hiba; a program viselkedése nem meghatározott és nagy valószínűséggel kataszt- 
rofális lesz. 
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Bizonyos Ct4-4-változatok automatikusan újrahasznosítják az elérhetetlen objektumok által 
elfoglalt memóriát (ezek a szemétgyűjtést alkalmazó megvalósítások), de viselkedésük nem 
szabványosított. Ha van is szemétgyűjtés, a delete operátor kétszeri meghívása egyben 
a destruktor (ha van ilyen) kétszeri meghívását fogja eredményezi, így az objektum kétszer 
törlődik, ami ilyenkor is súlyos hiba. A legtöbb esetben az objektumok ezen viselkedése 
csak apróbb kényelmetlenséget jelent. Jelesül, ahol van szemétgyűjtés, ott is a csak memó- 
ria-felszabadítást végző destruktorokat lehet megtakarítani. Ennek az egyszerűsítésnek 
a hordozhatóság elvesztése az ára, sőt bizonyos programoknál a futási idő növekedése és 
a viselkedés megjósolhatatlansága is (4C.9.1. 


Miután egy objektumot a delete művelettel töröltünk, bármilyen hozzáférési kísérlet az ob- 
jektumhoz hibának számít. Sajnos az egyes nyelvi változatok nem képesek megbízható mó- 
don jelezni az ilyen hibákat. 


A programozó megszabhatja, hogyan történjék a new használata esetén a memória lefogla- 
lása, illetve annak a delete-tel való felszabadítása (§6.2.6.2 és §15.609. Lehetséges a lefoglalás, 
a konstruktorok és a kivételek együttműködésének a megadása is (414.4.5 és 19.4.5). A sza- 
bad tárban levő tömböket a §10.4.7. tárgyalja. 


10.4.6. Osztály típusú tagok 


Nézzünk egy osztályt, amely egy kisebb cégről tárolhat adatokat: 


class Club f 
string name; 
Table members; 
Table officers; 
Date founded; 
VESS 
Club(const stringkt n, Date fd); 


A Club osztály konstruktoránál paraméterként meg kell adni a nevet és az alapítás dátumát. 
Az osztálytagok konstruktorainak paramétereit a tartalmazó osztály konstruktor- 


definiciójának tag-kezdőérték listájában (member initializer) adjuk meg: 


Club::Club(const stringk n, Date fd) 

: name(n), membersO, officersO, founded(d) 
( 

VAS 


j 
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A tagok kezdőérték-listáját kettőspont előzi meg és az egyes tagoknak kezdőértéket adó ki- 
fejezéseket vesszők választják el. 


A tagok konstruktorainak végrehajtása megelőzi a tartalmazó osztály saját konstruktora 
törzsének végrehajtását. A konstruktorok a tagoknak az osztály deklarációjában elfoglalt 
sorrendjében és nem a kezdőértéket adó kifejezéseknek a listában való felsorolási sorrend- 
jében hajtódnak végre. Az esetleges zavarok elkerülése érdekében nyilván célszerű a tago- 


kat a deklarációban elfoglalt sorrendjükben felvenni a kezdőérték-adó kifejezések listájára. 
A tagok destruktorai a konstruktorok sorrendjével ellenkező sorrendben hívódnak meg. 


Ha egy tag konstruktorának nincs szüksége paraméterre, nem szükséges felvenni a listára, 


így a következő kódrészlet egyenértékű az előző példabelivel: 


Club::Club(const stringge n, Date fd) 
: namern), founded(fd) 
( 


J 


VES 


A Table:: Table konstruktor a Club::officers tagot mindkét esetben a 75-tel, mint alapértel- 
mezett paraméterrel hozza létre. 


Ha egy osztálynak osztály típusú tagjai vannak, az osztály megsemmisítésekor először saját 
destruktor függvényének (ha van ilyen) törzse hívódik meg, majd a tagok destruktorai 
a deklarációval ellentétes sorrendben. A konstruktor alulról felfelé haladva (a tagokat elő- 
ször) építi fel a tagfüggvények végrehajtási környezetét, a destruktor pedig felülről lefelé 
(a tagokat utoljára) bontja le azt. 


10.4.6.1. A tagok szükségszerű kezdeti értékadása 


Azon tagok feltöltése kezdőértékkel szükségszerű, amelyeknél a kezdeti értékadás külön- 


bözik az egyszerű értékadástól — azaz az alapértelmezett konstruktor nélküli osztályba tar- 
tozó, a const és a referencia típusú tagoké: 


class Xf 
const int tí; 
Club c; 
Clubít pc; 
 ... 
XCint ti, const stringk n, Date d, Clubg c) : i(ii), c(n,d), pc(c) ( ? 
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Ezen tagok kezdeti értékadására nincs egyéb lehetőség, és hiba azt nem megtenni is. A leg- 
több típus esetében azonban a programozó választhat a kezdeti és a , sima" értékadás kö- 


zül. Ilyenkor én általában a tag-kezdőérték listás megoldást választom, hogy egyértelmű le- 
gyen a kezdeti értékadás ténye. Ez a módszer ráadásul hatékonyabb is: 


class Person ( 
string name; 
string address; 
age 
Person(const Persondt ); 
Person(const stringk n, const stringkt a); 
, 
Person::Person(const stringkt n, const string a) 
: namern) 
( 


address — a; 


j 


Itt a name az n egy másolatával kap kezdőértéket. Másfelől az address először egy üres ka- 
rakterlánccal töltődik fel, majd értékül az a egy másolatát kapja. 


10.4.6.2. Konstans tagok 


Egy statikus, egész típusú konstans tagot lehetséges a deklarációban egy kezdőérték-adó 
konstans kifejezéssel is feltölteni: 


class Curious ( 


bublic: 
static const int c1 — 7; // rendben, de ne felejtsük el a meghatározást 
static int c2 — 11; // hiba: nem állandó 
const int c3 — 13; // hiba: nem statikus 
static const int c4 - (17; // hiba: a kezdőérték-adó nem állandó 
static const float c5 — 7.O; // hiba: a kezdőérték-adó nem egész értékű 
Iza 


J; 


Akkor és csak akkor, ha a kezdőértéket kapott tagot memóriában tárolt objektumként hasz- 
náljuk, szükséges, hogy az ilyen tag (de csak egy helyen) definiált legyen, de ott nem sza- 


bad megismételni a kezdőérték-adó kifejezést: 
const int Curious::cI; —— // szükséges, de a kezdőérték-adó nem szerepelhet itt még egyszer 


const int?" p - kCurious::cI;  // rendben: Curious::c1 meghatározott 
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Másik megoldásként, jelképes állandóként használhatunk felsoroló konstanst (4.8, §14.4.6, 
§15.3) is az osztály deklarációján belül, ha szükséges: 








class Xf 
enum f c1 — 7, c2 - 11, c3 — 13, c4— 173; 
Má 

7 


Így a programozó nem fog kísértésbe esni, hogy az osztályban változóknak, lebegőpontos 


számoknak stb. adjon kezdőértéket. 


10.4.6.3. Tagok másolása 


Az alapértelmezett másoló konstruktor és az alapértelmezett másoló értékadás (410.4.4.1) 
az osztály összes tagját másolja. Ha ez nem lehetséges, az ilyen osztályú objektum másolá- 
si kísérlete hiba: 


class Unigue handle ( 
brivate: // a másoló műveleteket priváttá tesszük, megelőzendő az 
// alapértelmezett másolást (§11.2.2) 
Unigue handle(lconst Unigue handlek ); 
Unigue handlek operator-(const Unigue handlek ); 
bublic: 
178 
J; 


struct Y ( 
AES 
Unigue handlea; — // explicit kezdőértéket igényel 


3 


Y y1; 
Y y2 — y1; // hiba: Y::a nem másolható 


Ezenkívül az alapértelmezett értékadás nem jöhet létre a fordításkor, ha az osztály egy nem 
statikus tagja: referencia, konstans, vagy olyan felhasználói típus melynek nincsen másoló 
értékadása. 
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Jegyezzük meg, hogy a referencia típusú tagok ugyanarra az objektumra hivatkoznak az ere- 
deti objektumban és a másolatban is. Ez gond lehet, ha a hivatkozott objektumot törölni kell. 
Ha másoló konstruktort írunk, ügyeljünk arra, hogy minden tagot másoljunk, amelyet szük- 
séges. Alapértelmezés szerint az elemek alapértelmezett módon kapnak kezdőértéket, de 
sokszor nem erre van szükség egy másoló konstruktorban: 


Person::Person(const Personk a) : name(a.namoe) (í ? // vigyázat! 


Itt elfelejtettem az address tagot másolni, így az alapértelmezés szerinti üres karakterláncot 
kapja kezdőértékként. Ha új taggal bővítünk egy osztályt, ne felejtsük el ellenőrizni, hogy 
vannak-e olyan felhasználó által megadott konstruktorok, amelyeket az új tagok kezdeti ér- 


tékadására és másolására való tekintettel meg kell változtatni. 


10.4.7. Tömbök 


Ha egy osztály egy tagjának van alapértelmezett, azaz paraméter nélkül hívható kon- 
struktora, akkor ilyen osztályú objektumok tömbjét is meghatározhatjuk: 


Table tbl( 107; 


A fenti egy 10 7able elemből álló tömböt hoz létre és minden elemet a 7Table::TableO 
konstruktorral, a 15 értékű alapértelmezett paraméterrel tölt fel. 


A kezdőérték-lista (§45.2.1, §18.6.7) alkalmazásán kívül nincs más mód egy tömb elemeinek 
konstruktorai számára (nem alapértelmezett?) paramétereket megadni. Ha feltétlenül szük- 


séges, hogy egy tömb tagjai különböző kezdőértéket kapjanak, írjunk olyan alapértelmezett 
konstruktort, amely előállítja a kívánt értékeket: 


class Ibujffer ( 
string buj; 

bublic: 
IbufferO € cin:zbuj; ) 
4 vég 


J; 


void JO 
( 


Ibuffer words(100/;  // minden elem a cin-ről kap kezdőértéket 
Ves 


Az ilyen trükköket azonban általában jobb elkerülni. 
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Amikor egy tömb megsemmisül, az összes elemére meghívódik a destruktor. Ha nem new 
művelettel létrehozott tömbről van szó, akkor ez automatikusan történik. A C nyelvhez ha- 
sonlóan a Ctt sem különbözteti meg az egyedi elemre és a tömb kezdőelemére hivatkozó 
mutatót (45.30), ezért a programozónak meg kell adnia, hogy egyedi elemet vagy tömböt 
kell-e törölni: 


void f(int sz) 

f 
Table" t1 - new Table; 
Table" t2 - new Tablelszl[; 
Table" t3 - new Table; 
Table" tá - new Tablelszl[; 


delete t1; // helyes 
deletel ] 12; // helyes 
deletel ] 13; // helytelen; probléma 
delete t4; // helytelen; probléma 


A tömbök és egyedi elemek dinamikus tárterületen való elhelyezése az adott nyelvi válto- 
zattól függ. Ezért a különböző változatok különbözőképpen fognak viselkedni, ha hibásan 
használjuk a delete és deletel / operátorokat. Egyszerű és érdektelen esetekben, mint az elő- 
ző példa, a fordító észreveheti a hibát, de általában futtatáskor fog valami csúnya dolog 
történni. 


A kifejezetten tömbök törlésére szolgáló delete/ / logikailag nem szükséges. Elképzelhető 
lenne, hogy a szabad tártól megköveteljük, hogy minden objektumról tartsa nyilván, hogy 
egyedi objektum avagy tömb. Ekkor a nyilvántartás terhét levennénk a programozó vállá- 
ról, de ez a kötelezettség egyes C---változatokban jelentős memória- és futási idő-többletet 
jelentene. Ha az olvasó túl nehézkesnek találja a C stílusú tömbök használatát, itt is hasz- 
nálhat helyettük olyan osztályokat, mint a vector (§3.7.1, §16.39: 


void g0 

f 
vectorsTable:?" p1 - new vectorsTable:(109; 
Table? p2 - new Table; 


delete p1; 
delete p2; 
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10.4.8. Lokális statikus adatok 


A lokális statikus objektumok (§7.1.2) konstruktora akkor hajtódik végre, amikor a végre- 
hajtási szál először halad keresztül az objektum meghatározásán: 


void f(int i) 
(t 
static Table tbl; 
ZS 
if 00 ( 
static Table tbl2; 
ses 


J 


j 


int mainŐ 


( 
HOD; 
HD; 
HD; 
HZE 
j 
Itt tb/ konstruktora /Ó első meghívásakor hívódik meg. Mivel zbl-t statikusként adtuk meg, 
így nem semmisül meg, amikor /0-ből visszatér a vezérlés és nem jön újra létre //) máso- 
az (0) meghíváskor, tb/2 is csak (1) végrehajtásakor jön létre, a blokk újbóli végrehajtása- 
kor nem. 


A lokális statikus objektumok destruktorai akkor hívódnak meg, amikor a program leáll 
(49.4.1.1)9. Hogy pontosan mikor, az nincs meghatározva. 


10.4.9. Nem lokális adatok 


A függvényeken kívül meghatározott (azaz globális, névtérbeli és osztályhoz tartozó stati- 
kus) változók a mainO függvény meghívása előtt jönnek létre (és kapnak kezdőértéket), és 
minden létrehozott objektum destruktora a main függvényből való kilépés után végre fog 
hajtódni. A dinamikus könyvtárak használata (dinamikus csatolás) kissé bonyolultabbá te- 
szi ezt, hiszen ilyenkor a kezdeti értékadásra akkor kerül sor, amikor a dinamikus kód a fu- 


tó programhoz kapcsolódik. 
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A fordítási egységeken belül a nem lokális objektumok konstruktorainak végrehajtása 
a definiciójuk sorrendjében történik: 


class Xf 
TE tres 
static Table memtbl; 


J; 
Table tbl; 
Table X::memtbl; 


namespace Z (f 
Table tbl2; 


J 


A konstruktorok végrehajtási sorrendje a következő: tbl, X::memtbl, Z::tbl2. Vegyük észre, 
hogy a definíció és nem a deklaráció sorrendje számít. A destruktorok a konstruktorokkal 
ellentétes sorrendben hajtódnak végre: Z::tbl2, X::memtbli, tbl. 


Nincs nyelvi változattól független meghatározása annak, hogy az egyes fordítási egységek 
nem lokális objektumai milyen sorrendben jönnek létre: 


// file1.c: 
Table tbl1; 


// file2.c: 
Table tbl2; 


Az, hogy tbl7 vagy tbl2 fog előbb létrejönni, a Ct-4 adott változatától függ, de a sorrend 
azon belül is változhat. Dinamikus csatolás használata vagy akár a fordítási folyamat kis 
módosítása is megváltoztathatja a sorrendet. A destruktorok végrehajtási sorrendje is hason- 
lóan változatfüggő. 


Könyvtárak tervezésekor szükséges vagy egyszerűen kényelmes lehet egy olyan, 
konstruktorral és destruktorral bíró típus elkészítése, amely kizárólag a kezdeti értékadás és 
rendrakás célját szolgálja. Ilyen típusú adatot csak arra célra fogunk használni, hogy egy sta- 
tikus objektum számára memóriaterületet foglaljunk le azért, hogy lefusson a konstruktora 
és a destruktora: 


class Zlib init f 
Zlib init0; — // Zlib előkészítése használatra 
-Zlib initO; // Zlib utáni takarítás 

77 
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class Zlib f 
static Zlib init Xx; 


Md 


Jo 


Sajnos egy több fordítási egységből álló program esetében nincs garancia arra, hogy egy 
ilyen objektum kezdeti értékadása az első használat előtt megtörténik és a destruktor az 
utolsó használat után fut le. Egyes C---változatok biztosíthatják ezt, de a legtöbb nem. 
Programozói szinten azonban lehetséges azt a megoldást alkalmazni, amit a nyelvi változa- 
tok általában a lokális statikus objektumokra alkalmaznak: egy-egy, az első használatot fi- 
gyelő kapcsolót: 


class Zlib f 

static bool initialized; 

static void initialize0 ( /" kezdeti értékadás "/ initialized - true; ) 
bublic: 

// nincs konstruktor 


void JO 
( 


if Ginitialized -- false) initializeO; 
SZALA 


ML sé 


Jo 


Ha sok függvényben kell lekérdezni az első használatot figyelő kapcsolót, az fárasztó fel- 
adat lehet, de megoldható. Ez a módszer azon alapul, hogy a konstruktor nélküli statikus 
objektumok 0 kezdőértéket kapnak. A dolog akkor válik igazán problematikussá, ha az ob- 
jektum első használata egy végrehajtási időre érzékeny függvényben történik, ahol az ellen- 
őrzés és szükség esetén a kezdeti értékadás túl sok időt vehet igénybe. Ilyenkor további 
trükkökre van szükség (421.5.29. 


Egy lehetséges másik megközelítés, hogy az egyes objektumokat függvényekkel helyette- 
sítjük (49.4.1: 


intk objO f static int x - O; return x; ) // kezdeti értékadás első használatkor 


Az első használatot figyelő kapcsolók nem kezelnek minden elképzelhető helyzetet. Lehet- 
séges például olyan objektumokat megadni, amelyek a kezdeti értékadás alatt egymásra hi- 
vatkoznak - az ilyesmit jobb elkerülni. Ha mégis ilyen objektumokra van szükség, akkor 
óvatosan, fokozatosan kell létrehozni azokat. Egy másik probléma, hogy az utolsó haszná- 
latot nem tudjuk egy jelzővel jelezni. Ehelyett lásd §9.4.1.1 és §21.5.2. 


10. Osztályok 335 


10.4.10. Ideiglenes objektumok 


Ideiglenes objektumok legtöbbször aritmetikai kifejezésekből jönnek létre. Például az 
xyz kifejezés kiértékelése során egy ponton az x7?y részeredményt valahol tárolni kell. 
Hacsak nem a program gyorsításán dolgozik (411.6), a programozó ritkán kell, hogy az ide- 
iglenes objektumokkal törődjék, habár ez is előfordul (411.6, §22.4.7). 


Egy ideiglenes objektum, hacsak nincs referenciához kötve vagy nem egy nevesített objek- 


tumnak ad kezdőértéket, törlődik a tartalmazó teljes kifejezés kiértékelése végén. A teljes 
kifejezés olyan kifejezés, amely nem részkifejezése más kifejezésnek. 


A szabványos string osztály c strO nevű tagfüggvénye egy C stílusú, nullkarakterrel lezárt 
karaktertömböt ad vissza (§3.5.1, §20.4.19. A 4 operátor karakterláncok esetében összefűzést 
jelöl. Ezek nagyon hasznos dolgok a karakterláncok kezelésekor, de együttes használatuk 
furcsa problémákhoz vezethet: 


void ((stringé s1, string s2, stringk s3) 
( 
const char? cs - (514s529.c strO; 
coutl ££ cs; 
if (strlen(cs-(s24s3).c strO)c8 k.k cs[0/-- a) ( 
// cs használata 


J 
J 


Az olvasó valószínűleg azt mondja erre, hogy , nem kell ilyet csinálni", és egyetértek vele, 
de ilyen kódot szoktak írni, így érdemes tudni, hogyan kell azt értelmezni. 


Először egy ideiglenes, sztring osztályú objektum jön létre, amely az 51-52 művelet eredmé- 
nyét tárolja. Ettől az objektumtól aztán elkérjük a C stílusú karaktertömböt, majd a kifejezés 
végén az ideiglenes objektum törlődik. Vajon hol foglalt helyet a fordító a C stílusú karak- 
tertömb számára? Valószínűleg az s17--s2-t tartalmazó ideiglenes objektumban, és annak 
megsemmisülése után nem biztos, hogy nem semmisül meg az a terület is, következéskép- 
pen cs felszabadított memóriaterületre mutat. A cout CZ cs kimeneti művelet működhet 
a várt módon, de ez puszta szerencse kérdése. A fordítóprogram esetleg felderítheti az ilyen 
problémát és figyelmeztethet rá. 


Az if utasításos példa egy kicsit ravaszabb. Maga a feltétel a várakozásnak megfelelően fog 
működni, mert a teljes kifejezés, amelyben az s2--s3-at tartalmazó ideiglenes objektum lét- 
rejön, maga az iffeltétele. Mindazonáltal az ideiglenes objektum a feltételesen végrehajtan- 
dó utasítás végrehajtásának megkezdése előtt megsemmisül, így a cs változó bármiféle ot- 
tani használata nem biztos, hogy működik. 
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Vegyük észre, hogy ebben az esetben, mint sok más esetben is, az ideiglenes objektumok- 
kal kapcsolatos probléma abból adódik, hogy egy magasabb szintű adatot alacsony szinten 
használtunk. Egy tisztább programozási stílus nem csak jobban olvasható programrészletet 
eredményezett volna, de az ideiglenes objektumokkal kapcsolatos problémákat is teljesen 
elkerülte volna: 


void f(stringé s1, stringít s2, string 53) 
t 

cout 22 s14s2; 

string s — S24s3; 


if (s.lengthOs8 ££ s[0]J-—- a?) ( 
// s használata 


J 


j 


Ideiglenes változót használhatunk konstans referencia vagy nevesített objektum kezdőérté- 
keként is: 


void g(const string£, const string ); 


void h(stringé s1, stringét 52) 


( 
const stringí s — s14s2; 
string ss — S14s2; 
2(5, 559; // s és ss itt használható 


J 


Ez a kódrészlet jól működik. Az ideiglenes változó megsemmisül, amikor az , ő" hivatkozá- 
sát vagy nevesített objektumát tartalmazó kódblokk lefut. Emlékezzünk arra, hogy hiba egy 
lokális változóra mutató referenciát visszaadni egy függvényből (47.3) és hogy ideiglenes 
objektumot nem adhatunk egy nem konstans referencia kezdőértékéül (45.59. Ideiglenes 
változót létrehozhatunk kifejezett konstruktorhívással is: 


void (Shaped s, int x, int y) 
( 
s.move(Point(x,y)); // Point létrehozása a Shape::moveO) számára 


7 séta 


J 


Az ilyen módon létrehozott ideiglenes változók is ugyanolyan szabályok szerint semmisül- 
nek meg, mint az automatikusan létrehozottak. 
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10.4.11. Az objektumok elhelyezése 


A new operátor alapértelmezés szerint a szabad tárban hozza létre az objektumokat. Mit te- 
gyünk, ha máshol szeretnénk, hogy egy objektum létrejöjjön? Vegyünk példaként egy egy- 
szerű osztályt: 


class Xf 

bublic: 
X(in0); 
VMS 

J; 


Az objektumokat tetszés szerinti helyre tehetjük, ha megadunk egy memória-lefoglaló függ- 
vényt, amelynek további paraméterei vannak, és a new operátor használatakor megadjuk 
ezeket a paramétereket: 


void? operator neuw(size t, void?" p)freturnp;)  / explicit elhelyező operátor 


void? buf - reinterpret cast£void"-(OxFOOP); // fontos cím 
X: p2 - neu(bujptx; // X létrehozása a buf-ban, az operator 
// new(sizeof€xX), buf) meghívásával 


Ezen használat miatt a new (bujf) X utasításforma, amely az operator new-nak további pa- 
ramétereket ad, elhelyező utasításként (placement syntax) ismert. Jegyezzük meg, hogy 
minden new operátor a méretet várja első paraméterként, és ezt, mint a létrehozandó ob- 
jektum méretét, automatikusan megkapja (415.69. Hogy melyik operátort fogja egy adott hí- 
vás elérni, azt a szokásos paraméter-egyeztetési szabályok fogják eldönteni (47.49); minden 
newO operátornak egy size ttípusú első paramétere van. 

Az ,elhelyező" operator newO a legegyszerűbb ilyen lefoglaló függvény, és definiciója 
a Cnew: szabványos fejállományban szerepel. 


A reinterpret cast a , legdurvább" és a legnagyobb károkozásra képes a típuskonverziós 
operátorok közül (46.2.7). Legtöbbször egyszerűen a paraméterének megfelelő bitsorozatú 
értéket, mint a kívánt típust adja vissza, így aztán a lényegéből fakadóan nyelvi változattól 
függő, veszélyes és esetenként feltétlenül szükséges egészek és mutatók közötti átalakítás- 
ra használható. 


Az elhelyező new operátor felhasználható arra is, hogy egy bizonyos helyről (Arena objek- 
tumtól) foglaljunk memóriát: 
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class Arena ( 

bublic: 
virtual void"? allocísize b) -0O; 
virtual void free(void?) -O; 
A ég 


J; 


void? operator new(size t sz, Arena? a) 


( 


return a-salloc(sz); 


J 


A különböző Arena objektumokban szükség szerint tetszőleges típusú objektumokat hoz- 
hatunk létre: 


extern Arena? Persistent; 
extern Arena? Shared; 


void g(int í) 

( 
X: p - neu(Persistent) XCV; // X állandó tárterületen 
X: g - new(Shared) X(i; // X megosztott memóriában 
Md 


Ha egy objektumot olyan helyre helyezünk, amelyet nem (közvetlenül) a szabványos sza- 
badtár-kezelő kezel, némi óvatosságra van szükség annak megsemmisítésekor. Ennek alap- 
vető módja az, hogy közvetlenül meghívjuk a destruktort: 


void destroy(X" p, Arena" a) 


( 
b-2-XxO; // destruktor meghívása 
a- free(p9; // memória felszabadítása 
? 


J 
Jegyezzük meg, hogy a destruktorok közvetlen meghívását — csakúgy, mint az egyedi igé- 
nyeket kielégítő globális memória-lefoglalók — használatát inkább kerüljük el, ha lehet. Ese- 
tenként mégis alapvető szükségünk van rájuk: például nehéz lenne egy hatékonyan műkö- 
dő általános tárolóosztályt készíteni a standard könyvtár vector (§3.7.1, §16.3.8) típusa nyo- 
mán, közvetlen destruktorhívás nélkül. Mindazonáltal egy kezdő C---programozó inkább 
háromszor gondolja meg, mielőtt közvetlenül 
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meghívna egy destruktort és akkor is inkább kérje előtte tapasztalt kollégájának tanácsát. 
Az elhelyező operátor és a kivételkezelés kapcsolatáról lásd a §14.4.4-es pontot. 


A tömböknél nincs megfelelője az elhelyező operátornak, de nincs is szükség rá, mert az 
elhelyező operátort tetszőleges típusokra alkalmazhatjuk. Tömbökre vonatkozóan azonban 
megadhatunk például egyedi operator deleteO-et (419.4.5). 


10.4.12. Uniók 


Egy nevesített unió (union) olyan adatszerkezet (strucD, amelyben minden tag címe azo- 
nos (lásd §C.8.2). Egy uniónak lehetnek tagfüggvényei, de nem lehetnek statikus tagjai. 


A fordítóprogram általában nem tudhatja, hogy az unió melyik tagja van használatban, va- 
gyis nem ismert, hogy milyen típusú objektum van az unióban. Ezért egy uniónak nem le- 
het olyan tagja, amelynek konstruktorral vagy destruktorral rendelkezik, mert akkor nem 
lehetne a helyes memóriakezelést biztosítani, illetve azt, hogy az unió megsemmisülésével 
a megfelelő destruktor hívódik meg. 


Az uniók felhasználása leginkább alacsony szinten vagy olyan osztályok belsejében törté- 
nik, amelyek nyilvántartják, hogy mi van az unióban (§10.6[20D. 


10.5. Tanácsok 


[I] A fogalmakat osztályokra képezzük le. §10.1. 

[2] Csak akkor használjunk nyilvános adatokat (struct-okat), amikor tényleg csak 
adatok vannak és nincs rájuk nézve invariánst igénylő feltétel. §10.2.8. 

[3] A konkrét típusok a legegyszerűbb osztályok. Hacsak lehet, használjunk inkább 
konkrét típust, mint bonyolultabb osztályokat vagy egyszerű adatszerkezeteket. 
§10.3. 

I4] Egy függvény csak akkor legyen tagfüggvény, ha közvetlenül kell hozzáférnie 
az osztály ábrázolásához. §10.3.2. 

[5] Használjunk névteret arra, hogy nyilvánvalóvá tegyük egy osztálynak és segéd- 
függvényeinek összetartozását. §10.3.2. 

I6] Egy tagfüggvény, ha nem változatja meg az objektumának az értékét, legyen 
const tagfüggvény. §10.2.6. 

[7] Egy függvény, amelynek hozzá kell férnie az osztály ábrázolásához, de nem 
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[8] 
[91] 


[10] 


[11] 


[12] 


[13] 


[14] 


[15] 


[16] 


[17] 


[18] 


[19] 
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szükséges, hogy egy objektumon keresztül hívjuk meg, legyen statikus tagfügg- 
vény. §10.2.4. 

Az osztályra állapotbiztosítóit (invariáns) a konstruktorban állítsunk be. §10.3.1. 
Ha egy konstruktor lefoglal valamilyen erőforrást, akkor legyen destruktora az 
osztálynak, amelyik felszabadítja azt. §10.4.1. 

Ha egy osztálynak van mutató tagja, akkor legyenek másoló műveletei (másoló 
konstruktora és másoló értékadása). §10.4.4.1. 

Ha egy osztálynak van referencia tagja, valószínűleg szüksége lesz másoló mű- 
veletekre (másoló konstruktorra és másoló értékadásra) is. §10.4.6.3. 

Ha egy osztálynak szüksége van másoló műveletre vagy destruktorra, valószí- 
nűleg szüksége lesz konstruktorra, destruktorra, másoló konstruktorra és máso- 
ló értékadásra is. §10.4.4.1. 

A másoló értékadásnál ügyeljünk az önmagával való értékadásra. §10.4.4.1. 
Másoló konstruktor írásakor ügyeljünk arra, hogy minden szükséges elemet 
másoljunk (ügyeljünk az alapértelmezett kezdeti értékadásra). §10.4.4.1. 


Ha új taggal bővítünk egy osztályt, ellenőrizzük, nincsenek-e felhasználói 
konstruktorok, amelyekben kezdőértéket kell adni az új tagnak. 10.4.6.3. 
Használjunk felsoroló konstansokat, ha egész konstansokra van szükség egy 
osztály deklarációjában. §10.4.6.2. 

Globális vagy névtérhez tartozó objektumok használatakor kerüljük a végrehaj- 
tási sorrendtől való függést. §10.4.9. 

Használjunk első használatot jelző kapcsolókat, hogy a végrehajtási sorrendtől 
való függést a lehető legkisebbre csökkentsük. §10.4.9. 

Gondoljunk arra, hogy az ideiglenes objektumok annak a teljes kifejezésnek 


a végén megsemmisülnek, amelyben létrejöttek. §10.4.10. 


10.6. Gyakorlatok 


1: 


C1) Találjuk meg a hibát a §10.2.2-beli Date::add yearO függvényben. Aztán 
találjunk még két további hibát a §10.2.7-beli változatban. 


. (2.5) Fejezzük be és próbáljuk ki a Date osztályt. Írjuk újra úgy, hogy az adat- 


ábrázolásra az 1970.01.01. óta eltelt napokat használjuk. 


. 2) Keressünk egy kereskedelmi használatban levő Date osztályt. Elemezzük 


az általa nyújtott szolgáltatásokat. Ha lehetséges, vitassuk meg az osztályt egy 
tényleges felhasználóval. 


. (1 Hogyan érjük el a Cirono névtér Date osztályának set default függvényét 


(§10.3.29? Adjunk meg legalább három változatot. 


. (2) Határozzuk meg a Histogram osztályt, amely a konstruktorában paraméter- 
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ként megadott időtartományokra vonatkozó gyakoriságokat tartja nyilván. Biz- 
tosítsunk műveletet a grafikon kiíratására és kezeljük az értelmezési tartomá- 
nyon kívül eső értékeket is. 

6. (2) Határozzunk meg osztályokat, amelyek bizonyos (például egyenletes vagy 
exponenciális) eloszlások szerinti véletlen számokat adnak. Mindegyik osztály- 
nak legyen egy konstruktora, amely az eloszlást megadja, és egy draw függvé- 
nye, amely a következő értéket adja vissza. 

7. (2.5) Készítsük el a 7able osztályt, amely (név-érték) párokat tárol. Ezután mó- 
dosítsuk a számológép programot (§6.1), hogy az a map helyett a Table osztályt 
használja. Hasonlítsuk össze a két változatot. 

8. C2) Írjuk újra a §7.10[7]-beli Tnode-ot, mint olyan osztályt, amelynek konstruk- 
torai, destruktorai stb. vannak. Adjuk meg a Tnode-ok egy fáját, mint osztályt 
(konstruktorokkal és destruktorokka)]. 

9. (3) Határozzuk meg, készítsük el és ellenőrizzük az Intset osztályt, amely egé- 
szek halmazát ábrázolja. Legyen meg az unió, a metszet, és a szimmetrikus dif- 
ferencia művelet is. 

10.C"1.5) Módosítsuk az /nitset osztályt, hogy csomópontok (/Vode objektumok) hal- 
mazát jelentse, ahol a Node egy meghatározott adatszerkezet. 

11.(C"3) Hozzunk létre egy olyan osztályt, amely egész konstansokból és a -, -, " és 
/ műveletekből álló egyszerű aritmetikai kifejezéseket képes elemezni, kiérté- 
kelni, tárolni és kiírni. A nyilvános felület ilyesmi legyen: 


class Expr ( 
11 őt 
public: 
Expi(const char? ); 
int evalO; 
void printO; 
47 


Az Expr::ExprÓ konstruktor karakterlánc paramétere a kifejezés. Az Expr::evalÓ 
függvény visszaadja a kifejezés értékét, az Expr::printO pedig ábrázolja azt 
a cout-on. A program így nézhet ki: 


Expr x("7123/4412374-3"); 
cout c Ix — " cz x.eval0 cz NN; 


x.printO; 


Határozzuk meg az Expr osztályt kétféleképpen: egyszer mint csomópontok 
láncolt listáját, másszor egy karakterlánccal ábrázolva. Kísérletezzünk a kifejezés 
különböző kiíratásaival: teljesen zárójelezve, a műveleti jelet utótagként hasz- 
nálva, assembly kóddal stb. 
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12. C"2) Határozzuk meg a Char. gueue osztályt, hogy a nyilvános felület ne függ- 
jön az ábrázolástól. Készítsük el a Char. gueue-t mint (a) láncolt listát, illetve (b) 
vektort. 

13.C"3) Tervezzünk egy szimbólumtábla és egy szimbólumtábla-elem osztályt vala- 
mely nyelv számára. Nézzük meg az adott nyelv egy fordítóprogramjában, ho- 
gyan néznek ki ott az igazi szimbólumtáblák. 

14. C2) Módosítsuk a 10.6[11]-beli kifejezésosztályt, hogy változókat is kezelni tud- 
jon, valamint a — értékadó műveletet is. Használjuk a 10.6[131]-beli szimbólum- 
tábla osztályt. 

15.C"1) Adott a következő program: 


sinclude Ciostream: 


int mainŐ 


( 
std::cout CZ "Helló, világNm"; 


J 


Módosítsuk úgy, hogy a következő kimenetet adja: 


Kezdeti értékadás 
Helló, világ! 
Takarítás 


A mainO függvényt semmilyen módon nem változtathatjuk meg. 

16. (2) Határozzunk meg egy olyan Calculator osztályt, amilyet a §6.1-beli függvé- 
nyek nagyrészt megvalósítanak. Hozzunk létre Calculator objektumokat és al- 
kalmazzuk azokat a cin-ből származó bemenetre, a parancssori paraméterekre 
és a programban tárolt karakterláncokra. Tegyük lehetővé a kimenetnek a be- 
menethez hasonló módon többféle helyre való irányítását. 

17. (2) Határozzunk meg két osztályt, mindegyikben egy-egy statikus taggal, úgy, 
hogy mindegyik létrehozásához a másikra hivatkozunk. Hol fordulhat elő ilyes- 
mi igazi kódban? Hogyan lehet módosítani az osztályokat, hogy kiküszöböljük 
a végrehajtási sorrendtől való függést? 

18. (2.5) Hasonlítsuk össze a Date osztályt (410.3) az §5.9[13] és a §7.10[19] feladat- 
ra adott megoldással. Értékeljük a megtalált hibákat és gondoljuk meg, milyen 
különbségekkel kell számolni a két osztály módosításakor. 

19.(C3) Írjunk olyan függvényt, amely egy istream-ből és egy vectorcstring2-ből ki- 
indulva elkészít egy mapcstring, vectorsint: : objektumot, amely minden ka- 
rakterláncot és azok előfordulásának sorszámát tartalmazza. Futtassuk a progra- 
mot egy olyan szövegfájllal, amely legalább 1000 sort tartalmaz, és legalább 10 
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, Amikor én használok egy 
szót, azt értem alatta, 
amit én akarok — se többet, 
se kevesebbet." 

(Humpty Dumpty) 


Jelölés s Operátor függvények s Egy- és kétoperandusú műveleti jelek 9 Az operátorok 
előre meghatározott jelentése s Az operátorok felhasználói jelentése e Operátorok és név- 
terek " Komplex szám típusok e Tag és nem tag operátorok s Vegyes módú aritmetika e 
Kezdeti értékadás s Másolás s Konverziók e Literálok s Segédfüggvények s Konverziós 
operátorok e A többértelműség feloldása s Barát függvények és osztályok s Tagok és ba- 
rát függvények s Nagy objektumok s Értékadás és kezdeti értékadás s Indexelés s Függ- 
vényhívás e Indirekció e Növelés és csökkentés s Egy karakterlánc osztály 9 Tanácsok e 


Gyakorlatok 
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11.1. Bevezetés 


Minden műszaki szakterületnek — és a legtöbb nem műszakinak is — kialakultak a maga 
megszokott rövidítései, amelyek kényelmessé teszik a gyakran használt fogalmak kifejezé- 
sét, tárgyalását. Az alábbi például 


xtryiz 
világosabb számunkra, mint a 


vegyük y-t z-szer és az eredményt adjuk x-hez 


Nem lehet eléggé megbecsülni a szokásos műveletek tömör jelölésének fontosságát. 


A legtöbb nyelvvel együtt a C-t is támogat egy sor, a beépített típusokra vonatkozó műve- 
letet. A legtöbb fogalomnak, amelyre műveleteket szoktak alkalmazni, azonban nincs meg- 
felelője a beépített típusok között, így felhasználói típussal kell azokat ábrázolni. Például ha 
komplex számokkal akarunk számolni, ha mátrix-műveletekre, logikai jelölésekre vagy ka- 
rakterláncokra van szükségünk a C----ban, osztályokat használunk, hogy ezeket a fogalma- 
kat ábrázoljuk. Ha ezekre az osztályokra vonatkozó műveleteket definiálunk, megszokot- 
tabb és kényelmesebb jelölés felhasználásával kezelhetjük az objektumokat, mintha csak az 
alapvető függvény-jelölést használnánk. 


class complex f // nagyon leegyszerűsített complex típus 
double re, im; 

bublic: 
complex(double r, double i) : re(r), im(i) ( ) 
complex operatort(complex); 


complex operator" (complex); 


J; 


Itt például a komplex szám fogalmának egy egyszerű megvalósítását láthatjuk. Egy complex 
értéket egy kétszeres pontosságú lebegőpontos számpár ábrázol, melyet a - és a " műve- 
letek kezelnek. A felhasználó adja meg a complex::operatort0 és complex::operator?O 
operátorokat, hogy értelmezze a 4 és " műveleteket. Ha például b és c complex típusúak, 
akkor a b4tca b.oberator(c)-t jelenti. Ezek után közelítőleg meghatározhatjuk a complex szá- 
mokat tartalmazó kifejezések megszokott jelentését: 
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void JO 
í 


complex a - complex(1, 3.1; 
complex b - complex(1.2, 29; 
complex c — b; 


a — bic; 
b -— bicta; 
c - a:bacomplex(1, 29; 


J 


A szokásos kiértékelési szabályok érvényesek, így a második kifejezés azt jelenti, hogy 
b-b4(c?a), és nem azt, hogy b-(D4J"a. 


Az operátorok túlterhelésének legnyilvánvalóbb alkalmazásai közül sok konkrét típusokra 
vonatkozik (410.3). Az operátorok túlterhelése azonban nemcsak konkrét típusoknál hasz- 
nos. Általános és absztrakt felületek felépítésénél például gyakran használunk olyan operá- 
torokat, mint a -2, a /Jés a O. 


11.2. Operátor függvények 


A következő operátorok (46.2) jelentését meghatározó függvényeket megadhatjuk: 


si - iii Vá 90 N kk 

l - ! - z 5 1- 

-- k- - 99- Az ki 17 

2£ 55 55. az -- 7- cz 

5- kk I] 4 az -s j 

-5 [/ o new neul] delete deletel[ ] 


A következőknek viszont nem lehet felhasználói jelentést tulajdonítani: 


:: (hatókör-feloldás, §44.9.4, §10.2.4) 
. (tagkiválasztás, §5.7) 
.§ (tagkiválasztás a tagra hivatkozó mutatón keresztül, §15.5) 


Ezek olyan operátorok (műveleti jelek), amelyek második operandusként nem értéket, ha- 
nem nevet várnak és a tagokra való hivatkozás alapvető módjai. Ha túl lehetne terhelni eze- 
ket — azaz ha a felhasználó határozhatná meg jelentésüket — akkor ez érdekes mellékhatá- 
sokkal járhatna IStroustrup, 1994]. A háromparaméterű feltételes-kifezés operátor, a 2: 
(46.3.2) sem terhelhető túl, mint ahogy a sizeof(§4.6) és a typeid (§15.4.4) sem. 
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Új műveleti jeleket sem adhatunk meg; ehelyett a függvényhívási jelölés használható, ha 
a rendelkezésre állókon kívül további operátorokra is szükség van. Így például ne "ft-ot 
használjunk, hanem azt, hogy powO. Ezek a megszorítások túl szigorúnak tűnhetnek, de ru- 
galmasabb szabályok könnyen az egyértelműség elvesztéséhez vezetnének. Első pillantás- 
ra nyilvánvalónak és egyszerűnek tűnhet a "" operátort használni a hatványozásra, de gon- 
doljunk csak meg: a "?" műveleti jel balról kössön, mint a Fortranban, vagy jobbról, mint az 
Algolban? Az a"?p kifejezést hogyan értelmezzük: mint a"("p)-t vagy mint (a)F"(pJ-t? 


Az operátor függvények neve az operator kulcsszóból és azt követően magából az operá- 
torból áll; például operator c£. Az operátor függvényeket ugyanúgy deklarálhatjuk és hív- 
hatjuk meg, mint a többi függvényt. Az operátorral való jelölés csak az operátor függvény 
közvetlen meghívásának rövidítése: 


void (complex a, complex b) 
( 


complexc- at b; // rövid forma 
complex d - a.operator4(D); // explicit hívás 


j 


A complex előző definicióját adottnak véve a fenti két kezdeti értékadás jelentése azonos. 


11.2.1. Egy- és kétoperandusú műveletek 


Kétoperandusú műveleti jelet egyparaméterű nem statikus tagfüggvényként vagy kétpara- 
méterű nem tag függvényként definiálhatunk. Ha 0 kétoperandusú műveletet jelöl, akkor 
aagbb vagy aa.operatora(bb)-t, vagy oberatora(aa, bbJ-t jelöli. Ha mindkettő értelmezett, 
a túlterhelés-feloldási szabályok (§7.4) döntik el, melyik alkalmazható, illetve hogy egyálta- 
lán bármelyik alkalmazható-e: 


class X ( 

bublic: 
void operatort (int); 
XGND; 

z 

void operator4(X, XI; 

void operator4(X, double); 


void (X a) 

( 
a4 1; // a.operatora (1) 
1--a; // ::operatort(XC1), a) 


a41.O; // ::operatort (a, 1.0) 
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Az egyoperandusú (akár elő-, akár utótagként használb9) műveleti jelek paraméter nélküli 
nem statikus tagfüggvényként vagy egyparaméterű nem tag függvényként definiálhatók. 
Ha 0 előtag és egyoperandusú műveletet jelöl, akkor Oaa vagy aa.operatorO00-t, vagy 
operatora(aa)-t jelöli. Ha mindkettő értelmezett, a túlterhelés-feloldási szabályok (47.4) 
döntik el, melyik alkalmazható, illetve hogy egyáltalán bármelyik alkalmazható-e. Ha Oo 
utótag és egyoperandusú műveletet ad meg, akkor aa0 vagy aa.oberatora(int)-et, vagy 
operatora(aa,int)-et jelöli. (Ezt részletesebben a §11.11 pont írja le.) Ha mindkettő értel- 
mezett, ismét csak a túlterhelés-feloldási szabályok (§7.4) döntik el, melyik alkalmazható, il- 
letve hogy egyáltalán bármelyik alkalmazható-e. Operátort csak a nyelvi szabályoknak 
megfelelően definiálhatunk (§A.5), így nem lehet például egyoperandusú 960 vagy 
háromoperandusú 4 műveletünk: 


class Xf 
// tagok (a this" mutató automatikus): 


X? operatork O; // előtagként használt egyoperandusú £ (cím) 

X operatork (XI; // kétoperandusú £ (és) 

X operatort44(inD);  // utótagként használt növelő operátor (lásd §11.1) 
X operatorá(X,XI;  // hiba: háromoperandusú 

X operator/O; // hiba: egyoperandusú / 


Vai 


// nem tag függvények : 


X operator-(X); // előtagként használt egyoperandusúű mínusz (mínusz előjel) 
X operator-(X, XI; // kétoperandusú mínusz (kivonás) 

X operator--(Xk,int); // utótagként használt csökkentő operátor 

X operator-O; // hiba: nincs operandus 

X operator-(X, XX; // hiba: háromoperandusú 

X operatorm(X); // hiba: egyoberandusú 96 


A / J operátort a §11.8, a 0 operátort a §11.9, a -2 operátort a §11.10, a 4- és -- operátorokat 
a 11.11, a memóriafoglaló és felszabadító operátorokat a §6.2.6.2, a §10.4.11 és a §15.6 pon- 
tokban írjuk le. 


11.2.2. Az operátorok előre meghatározott jelentése 
A felhasználói operátorok jelentésének csak néhány előírásnak kell megfelelniük. 


Az operator-, operatorf ]J, operatorO és az operator-: nem statikus tagfüggvény kell, hogy 
legyen; ez biztosítja, hogy első operandusuk balérték (Ivalue) lesz (§4.9.6). 
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Bizonyos beépített operátorok jelentése megegyezik más operátoroknak ugyanazon para- 
méterre összetetten gyakorolt hatásával. Például ha a egy int, akkor 4-a jelentése meg- 
egyezik a1-1-gyel, ami pedig azt jelenti, hogy a-a1 17. Hacsak a felhasználó nem gondos- 
kodik róla, ilyen összefüggések nem állnak fenn a felhasználói operátorokra, így a fordító- 
program például nem fogja kitalálni a Z::operatort-O művelet jelentését pusztán abból, 
hogy megadtuk a Z::operator40 és Z::oberator-O műveleteket. 


Hagyományosan az - (értékadó), a £ (címképző) és a , (vessző; §6.2.2) operátorok előre 
definiáltak, ha osztályba tartozó objektumra alkalmazzuk azokat. Ezeket az előre meghatá- 
rozott jelentéseket az általános felhasználó elől elrejthetjük, ha privátként adjuk meg azokat: 


class X ( 

brivate: 
void operator—(const X£ ); 
void operatorát O; 
void operator, (const X£ ); 
Hdbes 


J; 


void (X a, X b) 


( 
a - b; // hiba: az értékadó operátor privát 
Ka; // hiba: a cím operátor (£ ) privát 
a, b; // hiba: a vessző operátor (, ) privát 


Alkalmas módon definiálva azonban új jelentés is tulajdonítható nekik. 


11.2.3. Operátorok és felhasználói típusok 


Az operátoroknak tagfüggvénynek kell lenniük vagy paramétereik között legalább egy fel- 
használói típusnak kell szerepelnie (kivételek ez alól a new és delete operátorok jelentését 
felülbíráló függvények.) Ez a szabály biztosítja, hogy a programozó egy kifejezés értelmét 
csak akkor módosíthassa, ha legalább egy felhasználói típus előfordul benne. Ebből adó- 
dóan nem definiálható olyan operátor, amely kizárólag mutatókkal működik. A C-- tehát 
bővíthető, de nem változtatható meg, (az osztályba tartozó objektumokra vonatkozó -, £ 
és , operátorokat kivéve). 


Az olyan operátorok, melyeket arra szánunk, hogy első paraméterként valamilyen alaptí- 
pust fogadjanak el, nem lehetnek tagfüggvények. Vegyük például azt az esetet, amikor egy 
complex változót akarunk a 2 egészhez hozzáadni: az aa--2 kifejezést alkalmas tagfüggvény 
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megléte esetén értelmezhetjük aa.operatort(29-ként, de a 2--aa kifejezést nem, mert nincs 
int osztály, amelynek - olyan tagfüggvénye lehetne, hogy a 2.operator(aa) eredményre jus- 
sunk. De ha lenne is, akkor is két tagfüggvény kellene ahhoz, hogy 2--aa-val és aa--2-vel 
is megbirkózzunk. Minthogy a fordítóprogram nem ismeri a felhasználói 4 művelet jelenté- 
sét, nem tételezheti fel róla a felcserélhetőséget (kommutativitás9), hogy annak alapján 


2-4da-t mint aa1-2-t kezelje. Az ilyesmit rendszerint nem tag függvényekkel kezelhetjük 


(§11.3.2, §11.59. 
A felsorolások felhasználói típusok, így rájuk is értelmezhetünk operátorokat: 


enum Day f sun, mon, tue, wed, thu, fri, sat ); 


Day£k operatort4(Dayk d) 
( 


J 


return d - (sat--d) ? sun : Day(d:3 1; 


A fordítóprogram minden kifejezést ellenőriz, hogy nem lép-e fel többértelműség. Ha egy 
felhasználói operátor is biztosít lehetséges értelmezést, a kifejezés ellenőrzése a §7.4 pont- 
ban leírtak szerint történik. 


11.2.4. Névterek operátorai 


Az operátor mindig valamilyen osztály tagja vagy valamilyen névtérben (esetleg a globális- 
ban) definiált. Vegyük például a standard könyvtár karakterlánc-kiírási műveletének egy- 


szerűsített változatát: 


namespace std f // egyszerűsített std 


class ostream ( 
1 sze 


ostreamk operators(const char"); 


55 
extern ostream cout; 


class string ( 
VATYT 
J; 


ostreamk operatorsostreamég, const stringé ); 
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int mainŐ 


( 
char? p - "Helló"; 


std::string s -— "világ"; 
std::cout 2Z pe " "az s cz INN; 


Ez természetesen azt írja ki, hogy , Helló, világ! . De miért? Vegyük észre, hogy nem tettem 
mindent elérhetővé az sid névtérből azáltal, hogy azt írtam volna: 


using namespace stid; 


Ehelyett az szd:: előtagot alkalmaztam a string és a cout előtt. Vagyis a legrendesebben vi- 
selkedve nem , szennyeztem be" a globális névteret és egyéb módon sem vezettem be szük- 
ségtelen függéseket. 


A C stílusú karakterláncok (char?) kimeneti művelete az std::ostream egy tagja, így 


std::cout £Z p 


jelentése definíció szerint: 


std::cout.operatorsz(p) 


Mivel azonban az szd::ostream-nek nincs olyan tagja, amelyet az std::string-re alkalmazhat- 
nánk, így 


std::cout 2 s 


jelentése: 


operatorsá(std::cout,s) 


A névtérben definiált operátorokat ugyanúgy operandusuk típusa szerint találhatjuk meg, 
mint ahogy a függvényeket paramétereik típusa szerint (§8.2.69. Minthogy a coutaz std név- 
térben van, így az sid is szóba kerül, amikor a cc számára alkalmas definíciót keresünk. Így 
aztán a fordítóprogram megtalálja és felhasználja a következő függvényt: 


std::operators£(std::ostreamd , const std::stringét ) 
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Jelöljön 0 egy kétoperandusú műveletet. Ha x az X típusba, az y pedig az Ytípusba tarto- 
zik, akkor x0y feloldása, azaz a paraméterek típusának megfelelő függvény megkeresése 
a következőképpen történik: 


46 Ha X egy osztály, keresünk egy operatorő-t, amely az X osztálynak vagy vala- 
melyik bázisosztályának tagfüggvénye. 

6 Keresünk egy operatorO deklarációt az xgy kifejezést körülvevő környezetben. 

Ha X az N névtér tagja, az oberatorO-t az N névtérben keressük. 

6 Ha Yaz M névtér tagja, az oberatorO-t az M névtérben keressük. 


e 


Ha az operatorO többféle deklarációját is megtaláltuk, a feloldási szabályokat kell alkalmaz- 
ni (47.4), hogy a legjobb egyezést megtaláljuk, ha egyáltalán van ilyen. Ez a keresési eljárás 
csak akkor alkalmazandó, ha legalább egy felhasználói típus szerepel az operandusok kö- 
zött, ami azt is jelenti, hogy a felhasználói konverziókat (411.3.2, §11.4) is figyelembe 
vesszük. (A typedef-fel megadott nevek csak szinonimák, nem felhasználói típusok 
(44.9.79.) Az egyoperandusú műveletek feloldása hasonlóan történik. 


Jegyezzük meg, hogy az operátorok feloldásában a tagfüggvények nem élveznek előnyt 
a nem tag függvényekkel szemben. Ez eltér a névvel megadott függvények keresésétől 
(48.2.6)9. Az operátorok el nem rejtése biztosítja, hogy a beépített operátorok nem válnak el- 
érhetetlenné, és hogy a felhasználó a meglevő osztálydeklarációk módosítása nélkül adhat 
meg új jelentéseket. A szabványos iostream könyvtár például definiálja a cc tagfüggvénye- 
ket a beépített típusokra, a felhasználó viszont a felhasználói típusoknak a cc művelettel va- 
ló kimenetre küldését az oszream osztály (421.2.1) módosítása nélkül definiálhatja. 


11.3. Komplex szám típusok 


A komplex számoknak a bevezetőben említett megvalósítása túl keveset nyújt ahhoz, hogy 
bárkinek is tessék. Egy matematika tankönyvet olvasva azt várnánk, hogy a következő 
függvény működik: 


void JO 
( 


complex a - complex(1, 29; 
complex b — 3; 

complex c - a42.3; 
complex d - 2--b; 

complex e -— -b-c; 

b — ct2tc; 
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Ráadásul elvárnánk, hogy létezzék néhány további művelet is, például a —— az összehason- 
lításra és a cc a kimenetre, és még a matematikai függvények (mint a sin és a sgrtO) meg- 
felelő készletét is igényelnénk. 


A complex osztály egy konkrét típus, így felépítése megfelel a §10.3-beli elveknek. Ráadá- 
sul a komplex aritmetika felhasználói olyan nagy mértékben építenek az operátorokra, 
hogy a complex osztály definiálása az operátor-túlterhelésre vonatkozó szinte valamennyi 
szabály alkalmazását igényli. 


11.3.1. Tag és nem tag operátorok 


Előnyös lenne, ha minél kevesebb függvény férne hozzá közvetlenül egy adott objektum 
belső adatábrázolásához. Ezt úgy érhetjük el, ha csak azokat az operátorokat adjuk meg 
magában az osztályban, amelyek értelmüknél fogva módosítják első paraméterüket, mint 
például a 4-. Azokat az operátorokat, amelyek csak egy új értéket állítanak elő paraméte- 
reik alapján, mint például a -, az osztályon kívül definiálom és az alapvető operátorok se- 
gítségével valósítom meg: 


class complex f 
double re, im; 
bublic: 
complexk operatort-(complex a); // hozzá kell férni az ábrázoláshoz 


Mé 


J; 


complex operatort(complex a, complex b) 


complex r — a; 
return r 47 b; // az ábrázolás elérése a 4- operátoron keresztül 


Ezen deklarációk alapján már leírhatjuk a következőt: 


void (complex x, complex y, complex z) 


( 
complex r1 — xtytz; //r1 - operators(operator4 (x,y), 2) 
complex r2 — x; Mr27-x 
r24-y; // r2.operator4-(y) 
r24- z; // r2.operator3 (2) 


Esetleges hatékonysági különbségektől eltekintve r7 és r2 kiszámítása egyenértékű. 


11. Operátorok túlterhelése 353 


Az összetett értékadó operátorokat, például a 4—-t és a §—-t általában könnyebb definiálni, 
mint egyszerű megfelelőiket, a t és " operátorokat. Ez többnyire meglepést kelt, pedig 
pusztán abból következik, hogy az összeadásnál 3 objektum játszik szerepet (a két össze- 
adandó és az eredmény), míg a 1 operátornál csak kettő. Az utóbbi esetében hatékonyabb 
a megvalósítás, ha nem használunk ideiglenes változókat: 


inline complexk complex::operatort-(complex a) 


re 4— a.re; 
im 47 a. im; 
return "this; 


A fenti megoldásnál nincs szükség ideiglenes változóra az eredmény tárolására és a fordí- 
tóprogram számára is könnyebb feladat a teljes helyben kifejtés. 


Egy jó fordítóprogram az optimálishoz közeli kódot készít a sima - operátor használata ese- 
tén is. De nincs mindig jó optimalizálónk és nem minden típus olyan , egyszerű", mint 
a complex, ezért a §11.5 pont tárgyalja, hogyan adhatunk meg olyan operátorokat, amelyek 
hozzáférhetnek az osztály ábrázolásához. 


11.3.2. Vegyes módú aritmetika 
Ahhoz, hogy a 


complex d - 2--b; 


kódot kezelni tudjuk, olyan 4 operátorra van szükségünk, amely különböző típusú paramé- 
tereket is elfogad. A Fortran kifejezésével élve tehát ,vegyes módú aritmetikára" (mixed- 
mode arithmetic) van szükség. Ezt könnyen megvalósíthatjuk, ha megadjuk az operátor 
megfelelő változatait: 


class complex ( 
double re, im; 
bublic: 
complexk operatort-(complex a) ( 
re 47 a.re; 
im 4- a. im; 
return "this; 
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complexk operatort-—(double a) f 
re 47 a; 
return "this; 


J 


ss 


jő 


complex operatort(complex a, complex b) 


( 
complex r — a; 
return r 47 b; // complex::operator4-(complex)-et hívja meg 
j 
complex operatort(complex a, double b) 
( 
complex r — a; 
return r 47 b; // complex::operator4-(double)-t hívja meg 


j 


complex operatort (double a, complex b) 


( 
complex r — b; 
return r 47 a; // complex::operator4-(double)-t hívja meg 


Egy double hozzáadása egy komplex számhoz egyszerűbb művelet, mint egy komplex 
szám hozzáadása; ezt tükrözik a fenti definíciók is. A double operandust kezelő műveletek 
nem érintik a komplex szám képzetes részét, így hatékonyabbak lesznek. 


A fenti deklarációk mellett most már leírhatjuk a következőt: 


void (complex x, complex y) 
( 


complexr1- xty; — // operator (complex, complex)-et hívja meg 
complex r2- xt2; — / operatort(complex, double)-t hívja meg 
complex r3 - 24x; — // oberatort(double,complex)-et hívja meg 


11.3.3. Kezdeti értékadás 


A complex változóknak skalárokkal való kezdeti és egyszerű értékadás kezeléséhez szüksé- 
günk van a skalárok (egész vagy lebegőpontos (valós) értékek) complex-szé átalakítására: 


complexb-3; — / b.re-3, b.im-0-t kell jelentenie 
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Az olyan konstruktor, amely egyetlen paramétert vár, konverziót jelent a paraméter típusá- 
ról a konstruktor típusára: 


class complex ( 
double re, im; 


bublic: 
complex(double r) : re(r), im(0) f ? 
ize 

Fé. 


Ez a konstruktor a valós számegyenesnek a komplex síkba való szokásos beágyazását 
jelenti. 


Egy konstruktor mindig azt írja elő, hogyan hozhatunk létre egy adott típusú értéket. Ha egy 
adott típusú értéket kell létrehozni egy (kezdeti vagy egyszerű) értékadó kifejezés értéké- 
ből és ebből egy konstruktor létre tudja hozni a kívánt típusú értéket, akkor konstruktort al- 
kalmazunk. Ezért az egyparaméterű konstruktorokat nem kell explicit meghívnunk: 


complex b — 3; 


A fenti egyenértékű a következővel: 


complex b - complex(3); 


Felhasználói konverzióra csak akkor kerül sor automatikusan, ha az egyértelmű (§7.4). Ar- 
ra nézve, hogyan adhatunk meg csak explicite meghívható konstruktorokat, lásd a §11.7.1 
pontot. 


Természetesen szükségünk lesz egy olyan konstruktorra is, amelynek két double típusú pa- 


ramétere van, és a (0,0) kezdőértéket adó alapértelmezett konstruktor is hasznos: 


class complex ( 
double re, im; 

bublic: 
complexO : re(0), im(0) f ) 
complex(double r) : re(r), im(0) f ) 
complex(double r, double i) : re(r), im(i) ( ) 
7 ési 

Fé 
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Alapértelmezett paraméter-értékeket használva így rövidíthetünk: 


class complex f 
double re, im; 

bublic: 
complex(double r -O, double i -0) : re(r), im() f ? 
si 


Ha egy típusnak van konstruktora, a kezdeti értékadásra nem használhatunk kezdőérték- 


listát (§5.7, §4.9.59: 


complex z1 — ( 3 3; // hiba: complex rendelkezik konstruktorral 
complex 22-13, 4); — / hiba: complex rendelkezik konstruktorral 


11.3.4. Másolás 


A megadott konstruktorokon kívül a complex osztálynak lesz egy alapértelmezett másoló 
konstruktora (410.2.5) is. Az alapértelmezett másoló konstruktor egyszerűen lemásolja a ta- 
gokat. A működést pontosan így határozhatnánk meg: 


class complex f 
double re, im; 
bublic: 
complex(const complexg c) : re(c.re), im(c.im) f ) 


4 se 


2; 
Én előnyben részesítem az alapértelmezett másoló konstruktort azon osztályok esetében, 
amelyeknél ez megfelelő. Rövidebb lesz a kód, mintha bármi mást írnék, és a kód olvasó- 
járól feltételezem, hogy ismeri az alapértelmezett működést. A fordítóprogram is ismeri és 
azt is, hogyan lehet azt optimalizálni. Ezenkívül pedig sok tag esetén fárasztó dolog kézzel 
kiírni a tagonkénti másolást és könnyű közben hibázni (§10.4.6.3). 


A másoló konstruktor paramétereként referenciát kell használnom. A másoló konstruktor ha- 
tározza meg a másolás jelentését — beleértve a paraméter másolásáét is — így a 


complex::complex(complex c) : re(c.re), im(c.im) f ) // hiba 


hibás, mert a függvény meghívása végtelen rekurzióhoz vezet. 
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Más, complex paraméterű függvények esetében én érték és nem referencia szerinti para- 
méter-átadást használok. Mindig az osztály készítője dönt. A felhasználó szemszögéből néz- 
ve nincs sok különbség egy complex és egy const complexk paramétert kapó függvény 
között. Erről bővebben ír a §11.6 pont. 


Elvileg a másoló konstruktort az ilyen egyszerű kezdeti értékadásoknál használjuk: 


complex x -— 2; // complex(2) létrehozása; ezzel adunk kezdőértéket x-nek 


complex y - complex(2,09; // complex(2,0) létrehozása; ezzel adunk kezdőértéket y-nak 


A fordítóprogram azonban optimalizál és elhagyja a másoló konstruktor meghívását. Írhat- 
tuk volna így is: 


complex x(29; // x kezdőértéke 2 
complex y(2,09; // y kezdőértéke (2,0) 


A complex-hez hasonló aritmetikai típusok esetében jobban kedvelem az - jel használatát. 
Ha a másoló konstruktort priváttá tesszük (411.2.2) vagy ha egy konstruktort explicit-ként 
adunk meg (§11.7.1), az — stílusú értékadás által elfogadható értékek körét a O stílusú ér- 
tékadás által elfogadotthoz képest korlátozhatjuk. 


A kezdeti értékadáshoz hasonlóan a két azonos osztályba tartozó objektum közötti érték- 
adás alapértelmezés szerint tagonkénti értékadást jelent (§10.2.5). A complex osztálynál er- 
re a célra megadhatnánk kifejezetten a complex::oberator- műveletet, de ilyen egyszerű 
osztály esetében erre nincs ok, mert az alapértelmezett működés pont megfelelő. 


A másoló konstruktor -— akár a fordítóprogram hozta létre, akár a programozó írta — nem- 
csak a változók kezdőértékének beállítására használatos, hanem paraméter-átadáskor, érték 
visszaadásakor és a kivételkezeléskor is (ásd §11.79. Ezek szerepét a nyelv a kezdeti érték- 
adáséval azonosként határozza meg (§7.1, §7.3, §14.2.1. 


11.3.5. Konstruktorok és konverziók 
A négy alapvető aritmetikai műveletnek eddig három-három változatát határoztuk meg: 


complex operatort (complex, complex); 
complex operatort (complex, double); 
complex operatort (double, complex); 


Ma 
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Ez fárasztóvá válhat, és ami fárasztó, ott könnyen előfordulhatnak hibák. Mi lenne, ha min- 
den paraméter háromféle típusú lehetne? Minden egyparaméterű műveletből három válto- 
zat kellene, a kétparaméterűekből kilenc, a háromparaméterűekből huszonhét és így to- 
vább. Ezek a változatok gyakran nagyon hasonlóak. Valójában majdnem mindegyik úgy 
működik, hogy a paramétereket egy közös típusra alakítja, majd egy szabványos algorit- 
must hajt végre. 


Ahelyett, hogy a paraméterek minden lehetséges párosítására megadnánk egy függvényt, 
típuskonverziókra hagyatkozhatunk. Tegyük fel, hogy complex osztályunknak van egy 
olyan konstruktora, amely egy double értéket alakít complex-szé, így a complex osztály szá- 
mára elég egyetlen egyenlőség-vizsgáló műveletet megadnunk: 


bool operator-—-(complex, complex); 


void (complex x, complex y) 


( 
X-zy; // jelentése oberator——(x,y) 
Xx-7-3; // jelentése operator-—(x, complex(3)) 
3—-—y; // jelentése oberator--(complex(3), y) 


J 


Lehetnek azonban okok, melyek miatt jobb külön függvényeket megadni. Egyes esetekben 
például a konverzió túl bonyolult művelet lehet, máskor bizonyos paramétertípusokra egy- 
szerűbb algoritmusok alkalmazhatók. Ahol ilyen okok nem lépnek fel jelentős mértékben, 
ott a függvény legáltalánosabb formáját megadva (esetleg néhány kritikus változattal kiegé- 
szítve) és a konverziókra hagyatkozva elkerülhetjük, hogy a vegyes módú aritmetikából 
adódóan nagyon sokféle függvényt kelljen megírnunk. 


Ha egy függvény vagy operátor több változattal rendelkezik, a fordítóprogram feladata 
a legalkalmasabb változat kiválasztása, a paramétertípusok és a lehetséges (szabványos 


vagy felhasználói) konverziók alapján. Ha nincs legjobb változat, a kifejezés többértelmű és 
hibás (ásd §7.2. 


Az olyan objektumok, melyeket a konstruktor közvetlen meghívása vagy automatikus hasz- 
nálata hozott létre, ideiglenes változónak számítanak és amint lehetséges, megsemmisülnek 
Cdásd §10.4.10). A . és --2 operátorok bal oldalán nem történik automatikus felhasználói 
konverzió. Ez akkor is így van, ha maga a . implicit (a kifejezésbe beleértetb: 


void g(complex 2) 

( 
3t2; // rendben: complex(3)z 
3.operatort—(2); // hiba: 3 nem egy osztály objektuma 
34—-z; // hiba: 3 nem egy osztály objektuma 
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Ezt kihasználva egy műveletet tagfüggvénnyé téve kifejezhetjük, hogy a művelet bal oldali 
operandusként balértéket vár. 


11.3.6. Literálok 


Osztály típusú literálokat nem definiálhatunk abban az értelemben, ahogyan 7.2 és 1.2e3 
double típusú literálok. Az alapvető típusokba tartozó literálokat viszont gyakran használ- 
hatjuk, ha a tagfüggvények fel vannak készítve a kezelésükre. Az egyparaméterű 
konstruktorok. általános eljárást biztosítanak erre a célra. Egyszerű és helyben kifejtett 
(inline) konstruktorok esetében ésszerű a literál paraméterű konstruktorhívásokra mint li- 
terálokra gondolni. A complex(3) kifejezést például én úgy tekintem, mint egy complex ér- 
tékű literált, noha a szó , technikai" értelmében véve nem az. 


11.3.7. Kiegészítő tagfüggvények 


Eddig csak konstruktorokat és aritmetikai műveleteket adtunk a complex osztályhoz. 


A tényleges használathoz ez kevés. A valós és a képzetes rész lekérdezése például sűrűn 
használatos: 


class complex (f 
double re, im; 

bublic: 
double real0 const f return re; ) 
double imagO const f return im; ) 
szar 

g 


A complex osztály többi tagfüggvényével ellentétben a realO és az imagO nem változtatja 
meg egy complex objektum értékét, így const-ként adható meg. 


A realÓ és imagO függvények alapján egy sor hasznos függvényt definiálhatunk anélkül, 
hogy azoknak hozzáférést kellene adnunk a complex osztály adatábrázolásához: 


inline bool operator-—(complex a, complex b) 


( 
J 


return a.real0--b.real0 kk a.imagO--b.imagO; 


Vegyük észre, hogy a valós és a képzetes részt elég olvasnunk, írnunk sokkal ritkábban kell. 
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Ha , részleges frissítésre" van szükségünk, a következőt írhatjuk: 


void (complexk z, double d) 
( 
/ 
z - complex(z.realO, d); // d hozzárendelése z.im-hez 


J 


Egy jól optimalizáló fordító ebből egyetlen értékadást készít. 


11.3.8. Segédfüggvények 


Ha mindent összerakunk, complex osztályunk így alakul: 


class complex f 
double re, im; 
bublic: 
complex(double r -O, double i -0) : re(r), im) ( ? 


double real0 const f return re; ) 
double imagO const f return im; ) 


complexk operatort-(complex); 
complexk operatort-(double); 
1 -, §-, és /7 


Kiegészítésként egy sor segédfüggvényt kell biztosítanunk: 


complex operatort(complex, complex); 
complex operatort(complex, double); 
complex operatort (double, complex); 


MI -, ?, és / 
complex operator-(complex); // egyoberandusú mínusz 
complex operatort(complex); // egyoberandusú plusz 


bool operator--(complex, complex); 
bool operator!1-(complex, complex); 


istreamék operator:P(istreamd , complexd ); // bemenet 
ostreamát operatorzz(ostreamdt , complex); // kimenet 
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Vegyük észre, hogy a real és imagO függvények szerepe alapvető az összehasonlító függ- 
vények definiálásában. A következő segédfüggvények is nagyrészt ezekre építenek. 


Megadhatnánk olyan függvényeket is, amelyek a polár-koordinátás jelölést támogatják: 


complex polar(double rho, double theta); 
complex conj(complex); 


double abs(complex); 
double arg(complex); 
double normícomplex); 


double real(complex); . // a kényelmesebb jelölésért 
double imag(complex);  // a kényelmesebb jelölésért 


Végül szükségünk lesz a további alapvető matematikai függvényekre: 


complex acos(complex); 
complex asin(complex); 
complex atan(complex); 


Ms. 


Felhasználói szemszögből nézve az itt bemutatott complex osztály szinte azonos 
a complexzdoubler-lal (ásd a standard könyvtárbeli ccomplex:-et, §22.59. 


11.4. Konverziós operátorok 


Konstruktorok használata típuskonverzió céljára kényelmes lehet, de nemkívánatos követ- 
kezményei vannak. Egy konstruktor nem tud 


1. automatikus átalakítást megadni felhasználói adattípusról beépített adattípusra 
(mert a beépített adattípusok nem osztályok) 
2. átalakítást megadni egy újabban megadott osztályról egy régebbire, a régebbi 


Ezeket a feladatokat az átalakítandó osztály konverziós Cátalakító) operátorának 
definiálásával oldhatjuk meg. Ha T egy típus neve, akkor az X::operator TO függvény hatá- 
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rozza meg az Xtípus T-re való konverzióját. Definiálhatunk például a 6 bites, nem negatív 
egészeket ábrázoló 7iny osztályt, melynek objektumait aritmetikai kifejezésekben szaba- 
don keverhetjük egészekkel: 


class Tiny ( 

char u; 

void assign(int i) f if (ik-077) throw Bad rangeO); v-i; ) 
bublic: 

class Bad range f 2); 


Tiny(int i) f assign(i); ) 
Tinyk operator-(int i) f assign(i); return "this; ) 


operator int) const f return u; ) // konverzió int típusra 
2. 


48 

Amikor egy Tiny egy egésztől kap értéket vagy kezdőértéket, ellenőrizzük, hogy az érték 
a megengedett tartományba esik-e. Minthogy egy 7Tiny másolásakor nincs szükség az érték- 
ellenőrzésre, az alapértelmezett másoló konstruktor és értékadás éppen megfelelő. 
Ahhoz, hogy a Tiny változókra is lehetővé tegyük az egészeknél szokásos műveleteket, ha- 
tározzuk meg a Tiny-ről int-re való automatikus konverziót, a JTiny::oberator intO-et. Je- 
gyezzük meg, hogy a konverzió céltípusa az operátor nevének része és nem szabad kiírni, 
mint a konverziós függvény visszatérési értékét: 


Tiny::operator intO const f return u; ) // helyes 
int Tiny::operator int() const f return u; ) // hiba 


Ilyen tekintetben a konverziós operátor a konstruktorra hasonlít. 
Ha egy int helyén egy Tiny szerepel, akkor arra a helyre a megfelelő int érték fog kerülni: 


int mainŐ 


( 
Tinyc1 - 2 
Tiny c2 - 62; 
Tiny c3 — c2-cI; //c3- 60 
Tiny c4 7 c3; // nincs tartományellenőrzés (nem szükséges) 
inti —- cI4c2; /i-64 
c1 - cl4c2 // tartományhiba: c1 nem lehet 64 
i — c3-64; /i--i 
c2 — c3-64; // tartományhiba: c2 nem lehet -4 


c3 — c4; // nincs tartományellenőrzés (nem szükséges) 
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A konverziós függvények különösen hasznosak olyan adatszerkezetek kezelésekor, ame- 
lyeknél az adatoknak (a konverziós operátor által definiált) kiolvasása egyszerű feladat, el- 


lentétben az értékadással és a kezdőérték-adással. 


Az istream és ostream típusok egy konverzió segítségével támogatják az alábbihoz hason- 
ló vezérlési szerkezeteket: 


while (cin:3x) coutSax; 


A cin:3x bemeneti művelet egy istreamdt referenciát ad vissza, amely automatikusan a cin 
objektum állapotát tükröző értékre alakítódik. Ezt azután a while utasítás ellenőrzi 
(421.3.3.). Általában azonban nem jó ötlet adatvesztéssel járó automatikus konverziót meg- 
határozni két típus között. 


Célszerű takarékoskodni a konverziós operátorok bevezetésével. Ha túl sok van belőlük, 
az a kifejezések többértelműségéhez vezethet. A többértelműséget mint hibát jelzi ugyan 
a fordítóprogram, de kiküszöbölni fáradságos lehet. Talán a legjobb eljárás az, ha kezdet- 
ben nevesített függvényekkel végeztetjük az átalakítást (például X::make int0). Ha később 
valamelyik ilyen függvény annyira népszerű lesz, hogy alkalmazása nem , elegáns" többé, 
akkor kicserélhetjük az X::operator intO konverziós operátorra. 


Ha vannak felhasználói konverziók és felhasználói operátorok is, lehetséges, hogy többér- 
telműség lép fel a felhasználói és a beépített operátorok között: 


int operatort(Tiny, Tiny); 


void KTiny t, int i) 
( 


J 


t-t; // hiba, többértelmű: operator4(t, Tiny(V) vagy int(D-i ? 


Ezért vagy felhasználói konverziókra építsünk, vagy felhasználói operátorokra, de ne mind- 
kettőre. 


11.4.1. Többértelműség 


Egy X osztályú objektum értékadása egy Vtípusú értékkel akkor megengedett, ha van olyan 
X::operator—(2) értékadó operátor, amely szerint Vtípus egyben Zis, vagy ha van egy egye- 
di konverzió V-ről Z-re. A kezdeti értékadásnál hasonló a helyzet. 
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Bizonyos esetekben a kívánt típusú értéket konstruktorok és konverziós operátorok ismé- 
telt alkalmazásával állíthatjuk elő. Ezt a helyzetet közvetlen konverzióval kell megoldani; az 
automatikus felhasználói konverzióknak csak egy szintje megengedett. Néha a kívánt típu- 
sú érték többféleképpen is létrehozható, ez pedig hiba: 


class Xf/£ ... "/ XCint); X(char?); ) ; 
class Yf€/? ... §/ YGND), ); 
class Z£/7 ...1/ ZCXI; ); 


X ff; 
Y fOD; 
ZD; 
void k10 
( 
KD; // hiba: többértelmű (XC€1) vagy KYC19)? 
HAI); // rendben 
HO; // rendben 
g("Mack"; // hiba: két felhasználói konverzió szükséges; 9((Z(XC"Mack"))-et 
// nem próbáltuk 
g(XC Doc; // rendben: g(Z(XCDoc"))) 
ez Suzy"; // rendben: g(zZ(XCSuzy"))) 


A felhasználói konverziókat a fordítóprogram csak akkor veszi figyelembe, ha szükségesek 
egy hívás feloldásához: 


class XX f/5 ... "/ XXGND, 3; 


void h(double); 
void h(XXx); 


void k20 


h(1; // h(double(1)) vagy h(XXC19)? h(double(1))! 


j 


A h(1) hívás a h(double(1)) hívást jelenti, mert ehhez csak egy szabványos (és nem felhasz- 
nálói) konverzióra van szükség (47.49). A konverziós szabályok se nem a legegyszerűbben 
megvalósítható, se nem a legegyszerűbben leírható, de nem is az elképzelhető legáltaláno- 
sabb szabályok. Viszont viszonylag biztonságosak és alkalmazásukkal kevésbé fordulnak 
elő meglepő eredmények. A programozónak sokkal könnyebb egy többértelműséget felol- 
dani, mint megtalálni egy hibát, amit egy nem sejtett konverzió alkalmazása okoz. 
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Az elemzés során alkalmazott szigorúan , alulról felfelé" való haladás elvéből az is követke- 
zik, hogy a visszatérési értéket nem vesszük figyelembe a túlterhelések feloldásakor: 


class Ouad f 

bublic: 
Ouad(double9; 
Jade 

J; 


Ouad operator (Ouad, Ouad); 


void (double a1, double a2) 
( 


Ouad r1 - altal; // kétszeres pontosságú összeadás 
Ouad r2 - Ouad(a1)-ta2; // Ouad aritmetika kikényszerítése 


A) 


Ezen tervezési mód választásának egyik oka, hogy a szigorú , alulról felfelé" való haladás el- 
ve érthetőbb, a másik pedig az, hogy nem a fordítóprogram dolga eldönteni, milyen fokú 
pontosságot akar a programozó egy összeadásnál. 

Ha egy kezdeti vagy egyszerű értékadás mindkét oldalának eldőlt a típusa, akkor az érték- 
adás feloldása ezen típusok figyelembe vételével történik: 


class Real f 


bublic: 
operator doubleO; 
operator intO; 
VAKES 
i 
void g(Real a) 
í 
double d — a; // d - a.doubleO; 
inti — a; /i- aintO; 
d - a; //d - a.doubleO; 
i — a; //i — a int0; 
) 


Az elemzés itt is alulról felfelé történik, egyszerre csak egy operátornak és paramétereinek 
figyelembe vételével. 
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11.5. Barát függvények 


Amikor egy függvényt egy osztály tagjaként adunk meg, három, logikailag különböző dol- 
got jelzünk: 


1. A függvény hozzáférhet az osztály deklarációjának privát részeihez. 

2. A függvény az osztály hatókörébe tartozik. 

3. A függvényt az osztály egy objektumára kell meghívni (egy this mutató áll 
a rendelkezésére). 


Ha egy tagfüggvényt static-ként határozunk meg (§10.2.4), akkor ez csak az első két tulaj- 
donságot jelenti; ha friend-ként ( barátként"), csak az elsőt. 


Definiáljunk például egy Matrix-ot egy Vector-ral szorzó operátort. Természetesen mind 
a Matrix, mind a Vector osztály alkalmazza az adatrejtés elvét, és csak tagfüggvényeiken ke- 
resztül kezelhetjük őket. A szorzást megvalósító függvény azonban nem lehet mindkét osz- 
tály tagja. Nem is akarunk általános, alacsonyszintű hozzáférést megengedni, hogy minden 
felhasználó írhassa és olvashassa a Matrix és Vector osztályok teljes adatábrázolását. Ahhoz, 
hogy ezt elkerüljük, a " operátort mindkét osztályban friend ( barát") függvényként hatá- 
rozzuk meg: 


class Matrix; 


class Vector f 
float ulál; 
26 
friend Vector operator" (const Matrixd, const Vectord ); 


J; 


class Matrix ( 
Vector ulál; 
MI tés 


friend Vector operator"(const Matrixk, const Vector ); 


J; 


Vector operator" (const Matrixkt m, const Vectorg v) 
( 
Vector Tr; 
for (int i - O; izd; 141) f 7 rlij - mlij ? v; 
r.ulí] — 0; 
for Gint j - O; jz4; ja) r.ulij 47 m.ulij. ulj] " v.uljj; 


J 


return Tr; 
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A friend deklarációt az osztály privát és nyilvános részébe is tehetjük. A tagfüggvényekhez 
hasonlóan a barát függvényeket is az osztály deklarációjában adjuk meg, így ugyanolyan 
mértékben hozzátartoznak az osztály felületéhez, mint a tagfüggvények. 


Egy osztály tagfüggvénye lehet egy másik osztály barát függvénye: 


class List iterator f 
1 
int? next; 


3ji, 


class List f 
friend int" List iterator::nextO; 
E ak 

21 


Nem szokatlan helyzet, hogy egy osztály összes tagfüggvénye egy másik osztály , barátja" . 
Ennek jelzésére egy rövidítés szolgál: 


class List f 
friend class List iterator; 
été 

j; 


E deklaráció hatására a List iterator osztály összes tagfüggvénye a List osztály barát függvé- 
nye lesz. 


Világos, hogy friend osztályokat csak szorosan összetartozó fogalmak kifejezésére szabad 
használnunk. Számos esetben viszont választhatunk, hogy egy osztályt tag (beágyazott osz- 
tály) vagy nem tag barátként adunk meg (424.4). 


11.5.1. A barát függvények elérése 


A tagfüggvények deklarációjához hasonlóan a friend deklarációk sem vezetnek be új nevet 
a tartalmazó hatókörbe: 


class Matrix f 
friend class Xform; 
friend Matrix invert(const Matrix ); 
Ve 

j; 


Xform x; // hiba: a hatókörben nincs Xform 
Matrix Cp)X(const Matrixg ) - kinvert; // hiba: a hatókörben nincs invertŐ 
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Nagy programok és osztályok esetében előnyös, ha egy osztály nem ad hozzá titokban új 
neveket a tartalmazó hatókörhöz, azoknál a sablon osztályoknál pedig, amelyek több kü- 
lönböző környezetben példányosíthatók (13. fejezet), ez kifejezetten fontos. 

A barát (friend) osztályt előzőleg meg kell adnunk a tartalmazó hatókörben vagy ki kell fej- 
tenünk az osztályt közvetlenül tartalmazó nem osztály típusú hatókörben. A közvetlenül 
tartalmazó névtér hatókörén kívüli neveket nem veszünk figyelembe: 


class AE€/5 ... 7); // nem "barátja" Y-nak 


namespace N f 
class X£/5... 73  /Yv"barátja" 
class Yf 
friend class X; 
friend class Z; 
friend class AE; 
2. 
J; 
class z€/5..."73 /Yv"barátja" 
2 


z 
A barát függvényeket ugyanúgy megadhatjuk pontosan, mint a barát osztályokat, de elér- 
hetjük paramétereik alapján is (§8.2.609, még akkor is, ha nem a közvetlenül tartalmazó 
hatókörben adtuk meg: 


void KMatrixk m) 
( 


invert(m); // a Matrix "barát" invert -je 


J 


Ebből következik, hogy egy barát függvényt vagy egy tartalmazó hatókörben kell közvet- 
lenül megadnunk, vagy az osztályának megfelelő paraméterrel kell rendelkeznie, máskü- 
lönben nem hívhatjuk meg: 


// a hatókörben nincs fÓ 


class X ( 
friend void fO; // értelmetlen 
friend void h(const X£ ); // paramétere alapján megtalálható 


J; 


void g(const X£ x) 

( 
JO; // a hatókörben nincs fO 
hCo; //XBhO "barátja" 


J 
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11.5.2. Barátok és tagfüggvények 


Mikor használjunk barát függvényt és mikor jobb választás egy tagfüggvény egy művelet szá- 
mára? Az első szempont egy osztálynál az, hogy minél kevesebb függvény érje el közvetle- 
nül az adatábrázolást és hogy az adatlekérdezést a segédfüggvények megfelelő körével tá- 
mogassuk. Ezért az elsődleges kérdés nem az, hogy , ez a függvény tag legyen, statikus tag 
vagy barát? , hanem az, hogy , tényleg szüksége van-e az ábrázolás elérésére?" Általában ke- 
vesebb függvénynek van erre ténylegesen szüksége, mint első ránézésre gondolnánk. 


Bizonyos műveleteknek tagoknak kell lenniük: például a konstruktoroknak, destruk- 
toroknak és a virtuális függvényeknek (412.2.69. Sokszor azonban van mérlegelési lehető- 
ség. Mivel egy tagfüggvény neve az osztályra nézve lokálisnak számít, a függvényt inkább 
tagfüggvényként adjuk meg, hacsak nem szól valamilyen érv amellett, hogy nem tag függ- 
vény legyen. 


Vegyünk egy X osztályt, amely egy művelet különféle módozatait jeleníti meg: 


class Xf 
MI 
X(inD); 


int m1O; 
int m20 const; 


friend int fICX£ ); 
friend int f2Xconst X£ ); 
friend int f3(X; 

j; 


A tagfüggvényeket csak az adott osztály objektumaira alkalmazhatjuk; felhasználói átalakí- 
tást a fordító nem végez: 


void g0 


99.m10O; // hiba: nem próbáltuk X(99).m10-et 
99.m20O; // hiba: nem próbáltuk X(99).m20-őt 


J 


Az X(int) átalakítást a fordító nem alkalmazza, hogy a 99-ből X típusú objektumot csináljon. 


Az fIO globális függvény hasonló tulajdonsággal rendelkezik, mert nem const referencia 
paraméterekre a fordító nem alkalmaz felhasználói átalakítást (45.5, §11.3.59. Az /20 és 30 
paramétereire azonban alkalmazható ilyen: 
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void hO 


( 
JI(999;/ hiba: nem próbáltuk fIC(XC99)9-et 
J2(999; / rendben: f2CXC99)9; 


J3(999; / rendben: f3CXC99)9; 
? 


sÉ 
Ezért egy, az objektum állapotát megváltoztató művelet vagy tag legyen, vagy pedig nem 
const referencia (vagy nem const mutató) paraméterű globális függvény. Olyan műveletet, 
amelynek balértékre van szüksége, ha alapvető adattípusra alkalmazzuk (-, "-, 4-4 stb.), 
a legtermészetesebb módon felhasználói típus tagfüggvényeként definiálhatunk. 


Megfordítva: ha egy művelet összes operandusa automatikusan konvertálható, akkor 
a megvalósító függvény csak olyan nem tag függvény lehet, amely paraméterként const 
referencia vagy nem referencia típust vár. Ez gyakori eset olyan műveleteket megvalósító 
függvényeknél, melyeknek nincs szükségük balértékre, ha alapvető adattípusra alkalmaz- 
zuk azokat (-4, -, I I stb.)9. Az ilyen műveleteknek gyakran az operandus-osztály ábrázolásá- 
nak elérésére van szükségük, ezért aztán a kétoperandusú operátorok a friend függvények 
leggyakoribb forrásai. 


Ha nincs típuskonverzió, akkor nincs kényszerítő ok arra sem, hogy válasszunk a tagfügg- 
vény és a referencia paramétert váró barát függvény közül. Ilyenkor a programozó aszerint 
dönthet, hogy melyik formát részesíti előnyben. A legtöbb embernek például jobban tetszik 
az imu(m) jelölés, ha egy m Matrix inverzéről van szó, mint a másik lehetséges m.invO je- 
lölés. Ha azonban az inyO azt a Matrix-ot invertálja, amelyikre alkalmaztuk és nem egy új 
Matrix-ként adja vissza az inverzt, akkor persze csak tagfüggvény lehet. 


Ha más szempontok nem játszanak közre, válasszunk tagfüggvényt. Nem tudhatjuk, hogy 
valaki nem ad-e majd meg valamikor egy konverziós operátort, és azt sem láthatjuk előre, 
hogy egy jövőbeli módosítás nem változtatja-e meg az objektum állapotát. A tagfüggvény- 
hívási forma világossá teszi a felhasználó számára, hogy az objektum állapota megváltoz- 
hat; referencia paraméter használata esetén ez sokkal kevésbé nyilvánvaló. Továbbá sokkal 
rövidebbek a kifejezések egy tagfüggvény törzsében, mint a külső függvénybeli megfelelő- 
ik; egy nem tag függvénynek meghatározott paraméterre van szüksége, míg a tagfüggvény 
automatikusan használhatja a t/iis mutatót. Ezenkívül, mivel a tagfüggvények neve az osz- 
tályra nézve lokálisnak számít, a külső függvények neve hosszabb szokott lenni. 
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11.6. Nagy objektumok 


A complex osztály műveleteinek paramétereit complex típusúként határoztuk meg. Ez azt 
jelenti, hogy a paraméterek minden műveletnél lemásolódnak. Két double másolása , költ- 
séges" művelet lehet ugyan, de valószínűleg , olcsóbb", mint egy pár mutatóé. Nem minden 
osztálynak van azonban kényelmesen kicsi ábrázolása. A nagymérvű másolásokat elke- 
rülendő, megadhatunk referencia típusú paramétereket kezelő függvényeket: 


class Matrix f 
double mlájlál; 
public: 
MatrixO; 
friend Matrix operator4(const Matrix, const Matrix£ ); 
friend Matrix operator" (const Matrixk, const Matrix ); 


); 


A referenciák alkalmazása nagy objektumokra is lehetővé teszi a szokásos aritmetikai mű- 
veletek használatát, nagymérvű másolások nélkül is. Mutatókat nem használhatunk, mert 
a mutatóra alkalmazott operátorok jelentését nem változtathatjuk meg. Az összeadást így 
definiálhatnánk: 


Matrix operator:3(const Matrix arg1, const Matrixk arg2) 


t 
Matrix sum; 
for (int i-O; izd; 134) 
for (int j-O; jz4; j414) 
sum. mlillj] - arg1.mlillj] 4 arg2.mlillj[; 
return sum; 
J 


Ez az operatort0 az operandusokat referenciákon keresztül éri el, de objektum-értéket ad 
vissza. Referenciát visszaadni hatékonyabbnak tűnhet: 


class Matrix f 
HM va 
friend Matrixk operatort(const Matrixk, const Matrixő ); 
friend Matrixdt operator"(const Matrixdt, const Matrixdt ); 


); 


Ez szabályos kód, de egy memória-lefoglalási problémát okoz. Minthogy a függvényből az 
eredményre vonatkozó referenciát adjuk vissza, az eredmény maga nem lehet automatikus 
változó (47.39. Mivel egy műveletet többször is alkalmazhatunk egy kifejezésen belül, az 
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eredmény nem lehet lokális statikus változó sem. Ezért aztán az eredménynek jellemzően 
a szabad tárban foglalnánk helyet. A visszatérési érték másolása (végrehajtási időben, kód- 
és adatméretben mérve) gyakran olcsóbb, mint az objektum szabad tárba helyezése és on- 
nan eltávolítása, és programozni is sokkal egyszerűbb. 


Az eredmény másolásának elkerülésére vannak módszerek. A legegyszerűbb ezek közül 
egy statikus objektumokból álló átmeneti tár használata: 


const max matrix temp — 7; 


Matrixk get matrix. tempO 


( 
static int nbuf - 0; 
static Matrix buflmax matrix templ; 


if (nbuf -—- max matrix. temp) nbuf - 0; 
return bujlnbuf4a]; 


J 


Matrix£k operatort(const Matrix arg1, const Matrixk arg2) 


( 
Matrixk res - get matrix tempO; 
Jess 


return res; 
2 


8 3 
Így egy Matrix másolása csak egy kifejezés értékén alapuló értékadáskor történik meg. De 
az ég legyen irgalmas, ha olyan kifejezést találnánk írni, amelyhez max matrix temp-nél 
több ideiglenes érték kell! 


Hibákra kevesebb lehetőséget adó módszer, ha a mátrix típust csak a tényleges adatot táro- 
ló típus leírójaként (handle, §25.7) határozzuk meg. Így aztán a mátrixleírók úgy képvi- 
selhetik az objektumokat, hogy közben a lehető legkevesebb helyfoglalás és másolás törté- 
nik (411.12 és §11.14I18D. Ez az eljárás azonban a visszatérési értékként objektumot és nem 
referenciát vagy mutatót használó operátorokon alapul. Egy másik módszer háromváltozós 
műveletek meghatározására és azok olyankor automatikusan történő meghívására támasz- 
kodik, amikor olyan kifejezések kiértékelése történik, mint a-btc vagy atb?i (§21.4.6.3 és 
422.4.79. 
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11.7. Alapvető operátorok 


Általánosságban, ha X egy típus, akkor az X(const X£) másoló konstruktor kezeli azt az 


esetet, amikor egy X típusú objektumnak egy ugyanilyen objektumot adunk kezdőértékül. 
Nem lehet eléggé hangsúlyozni, hogy a kezdeti és az egyszerű értékadás különböző műve- 
letek (§10.4.4.19. Ez különösen fontos akkor, amikor a destruktorral is számolnunk kell. Ha 
az X osztálynak van valamilyen nem magától értetődő feladatot — például a szabad tárban 
lefoglalt memória felszabadítását — végző destruktora, akkor az osztálynak valószínűleg 
szüksége lesz az objektum létrehozását, megsemmisítését és másolását végző összes függ- 


vényre: 

class Xf 
JA 
X(SometypeJ; // konstruktor: objektumok létrehozása 
X(const X£ ); // másoló konstruktor 
X£ operator—(const X£ ); // másoló értékadás: takarítás és másolás 
-XO; // destruktor: takarítás 

J; 


Ezenkívül még háromféle helyzetben másolódik egy objektum: átadott függvény- 
paraméterként, függvény visszatérési értékeként, illetve kivételként. Ha paraméterként ke- 
rül átadásra, egy addig kezdőérték nélküli változó, a formális paraméter kap kezdőértéket. 
Ennek szerepe azonos az egyéb kezdeti értékadásokéval. Ugyanez igaz a visszatérési érték- 
re és a kivételre is, még ha kevésbé nyilvánvaló is. Ilyen esetben a másoló konstruktor vég- 


zi a munkát: 


string g(string arg) // string érték szerint átadva (másoló konstruktor használatával) 
f 
return arg; // string visszaadása (másoló konstruktor használatával) 
j 
int main O 
f 
string s - "Newton";  // string kezdőértéket kap (másoló konstruktor használatával) 
s - 95); 
J 


Világos, hogy az s változó értékének "Newton"-nak kell lennie a g0 meghívása után. Nem 
nehéz feladat az s értékének egy másolatát az arg formális paraméterbe másolni; a string 
osztály másoló konstruktorának hívása ezt megteszi. Amikor g0 visszaadja a visszatérési ér- 
téket, a string(const stringf) újabb hívása következik, amikor egy olyan ideiglenes 
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változó kap értéket, amely aztán az s-nek ad értéket. Hatékonysági okokból az egyik (de 
csak az egyik) másolást gyakran elhagyhatjuk. Az ideiglenes változók aztán persze 
a string::-stringŐ destruktor segítségével megsemmisülnek (§10.4.10). 


Ha a programozó nem ad meg másoló konstruktort vagy másoló értékadást egy osztály szá- 
mára, a fordítóprogram hozza létre a hiányzó függvényt vagy függvényeket (410.2.5). 
Ez egyben azt is jelenti, hogy a másoló műveletek nem öröklődnek (§12.2.3). 


11.7.1. Explicit konstruktorok 


Alapértelmezés szerint az egyparaméterű konstruktor egyben automatikus konverziót is je- 
lent. Bizonyos típusok számára ez ideális: 


complexz- 2; — /z kezdeti értékadása complex(29-vel 


Máskor viszont nem kívánatos és hibák forrása lehet: 


string s - a; /7/ s karakterlánc, int( a!) számű elemmel 
Nagyon valószínűtlen, hogy az s-et megadó programozó ezt akarta volna. 


Az automatikus konverziókat az explicit kulcsszó alkalmazásával akadályozhatjuk meg. Va- 
gyis egy explicit-ként megadott konstruktort csak közvetlen módon lehet meghívni. Így 
ahol elvileg egy másoló konstruktorra van szükség (411.3.4), ott az explicit konstruktor nem 
hívódik meg automatikusan: 


class String ( 
Ms 
explicit String(int n); // n bájt lefoglalása 


String(const char? p);// a kezdőérték (p) egy C stílusú karakterlánc 


J; 


String s1 — a; // hiba: nincs automatikus char--String átalakítás 
String S2(109; // rendben: String 10 karakternyi hellyel 

String s3 - String(10); " // rendben: String 10 karakternyi hellyel 

String s4 — "Brian"; // rendben: s4 - String("Brian") 

String s5("Fawlty"); 

void (String); 

String gO 


( 
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H109; // hiba: nincs automatikus int -2String átalakítás 
KStringC10)9; 

JO Arthur"); // rendben: KStringCArthur")) 

HSDU; 


String? p1 - new String(TEric"); 
String? p2 - new String(109; 


return 10; // hiba: nincs automatikus int -2String átalakítás 


J 
A különbség aközött, hogy 


String 51 — a; // hiba: nincs automatikus char --String átalakítás 
és aközött, hogy 

String S2(C109; // rendben: karakterlánc 10 karakternyi hellyel 
csekélynek tűnhet, de igazi kódban kevésbé az, mint kitalált példákban. 


A Date osztályban egy sima int-et használtunk az év ábrázolására (§10.3). Ha a Date osztály 
létfontosságú szerepet játszott volna, akkor bevezethettük volna a Year osztályt, hogy for- 
dítási időben szigorúbb ellenőrzések történjenek: 


class Year ( 
int y; 

public: 
explicit YearGint i) : y(i) ( ? // Year létrehozása int-ből 
operator int) const (f return y; ) // átalakítás Year-ről int-re 


Vé 


class Date ( 

pbublic: 
Date(int d, Month m, Year y); 
VAS 

J; 


Date d3(1978 feb, 21; // hiba: a 21 nem Year típusú 
Date d4(21 feb, YearC1978)9; // rendben 


A Year egy egyszerű , csomagoló" (beburkoló, wrapper) osztály az int körül. Az operator 
int0-nek köszönhetően a Year automatikusan mindenhol int-té alakul, ahol szükséges. Az- 
által, hogy a konstruktort explicit-ként adtuk meg, biztosítottuk, hogy az int-nek Year-ré va- 
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ló alakítása csak ott történik meg, ahol ezt kérjük és a , véletlen" értékadások a fordításkor 
kiderülnek. Minthogy a Yeartagfüggvényeit könnyű helyben kifejtve (inline) fordítani, a fu- 
tási idő és a szükséges tárhely növekedésétől sem kell tartanunk. 


Hasonló módszer tartomány (intervallum) típusokra (425.6.1) is alkalmazható. 


11.8. Indexelés 


Osztály típusú objektumoknak az operator / / (subscripting) függvény segítségével adha- 
tunk , sorszámot" (indexet). Az operatorf / második paramétere (az index) bármilyen típusú 
lehet, így aztán vektorokat, asszociatív tömböket stb. is definiálhatunk. 


Példaként írjuk most újra a §5.5-beli példát, amelyben egy asszociatív tömb segítségével ír- 
tunk egy fájlban a szavak előfordulását megszámoló kis programot. Akkor egy függvényt 
használtunk, most egy asszociatív tömb típust: 


class Assoc f 
struct Pair f 
string name; 
double val; 
Paircstring n -"", double v -0) :name(n), val) ( ) 
) 
vectorZ Pair? vec; 


Assoc(const Assoc£ ); // a másolást megakadályozandó privát 

Assock operator-(const ASSOcdt ); // a másolást megakadályozandó privát 
bublic: 

AssocO 13 


const doublek operatorl [(const string ); 
doubleg operatorl [(string£ ); 
void print allOÓ const; 


Az Assoc típusú objektumok Pair-ek vektorát tartalmazzák. A megvalósításban ugyanazt az 
egyszerű és nem túl hatékony keresési módszert használjuk, mint az §5.5 pontban: 


doublek Assoc::operatorl (string 5) 
// megkeressük s-t; ha megtaláltuk, visszaadjuk az értékét; ha nem, új Pair-t hozunk 
// létre és az alapértelmezett O értéket adjuk vissza 


( 
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for (vectorSPair2::iterator p - vec.beginO; p!-vec.endO; 44p) 
if (s -—- p--xname) return p-:val; 


vec.push back(PairCs,0)); // kezdőérték: O 


return vec.backO.val; // az utolsó elem visszaadása (f§16.3.3) 


Minthogy az Assoc objektum ábrázolása kívülről nem érhető el, szükség van egy kimeneti 
függvényre: 


void Assoc::print all const 


( 
for (vectorgPair:::const iterator p - vec.beginO; p!-vec.endO); 44p) 
cout ££ p-xname cc ": " c£ p-xval cz Mi; 


J 


Végül megírhatjuk a főprogram egyszerű változatát: 


int mainŐ // szavak előfordulásának megszámlálása a bemeneten 
f 

string buj; 

ASSOC VeCc; 


while (cin:zzbup) veclbujfj4-4; 
vec.print allO; 


Az asszociatív tömb ötletét továbbfejleszti a §17.4.1 pont. 


Az operatorf JO függvényeknek tagfüggvénynek kell lenniük. 


11.9. Függvényhívás 


A függvényhívás (function calD, vagyis a kifejezés(kifejezés-lista) jelölés úgy tekinthető, 
mint egy kétoperandusú művelet, ahol a kifejezés a bal oldali, a kifejezés-lista pedig a jobb 
oldali operandus. A 0 hívó operátor a többi operátorhoz hasonló módon túlterhelhető. 
Az operatorOO paraméterlistájának kiértékelése és ellenőrzése a szokásos paraméter-átadá- 
si szabályok szerint történik. A függvényhívó operátor túlterhelése elsősorban olyan típu- 
sok létrehozásakor hasznos, amelyeknek csak egy műveletük van vagy általában csak egy 
műveletük használatos. 
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A 0 hívó művelet legnyilvánvalóbb és talán legfontosabb alkalmazása az, hogy a valami- 
képpen függvényként viselkedő objektumokat függvényként hívhassuk meg. Egy függ- 
vényként viselkedő objektumot függvényszerű vagy egyszerűen függvényobjektumnak hí- 
vunk (§18.4). Az ilyen függvényobjektumok fontosak, mert lehetővé teszik, hogy olyan kó- 
dot írjunk, amelyben valamilyen nem magától értetődő műveletet paraméterként adunk át. 
A standard könyvtárban például sok olyan algoritmus található, melyek egy függvényt hív- 
nak meg egy tároló minden elemére. Vegyük az alábbi példát: 


void negate(complexk c) ( c — -c; ) 


void fwvectorccomplex-k aa, listccomplex-zk ID 


( 


Jor. each(aa.beginO, aa.endO, negate); // a vektor összes elemének negálása 


for. each(ll.beginO, II.endO, negate); // a lista összes elemének negálása 
2 
J 


Ez a vektor és a lista minden elemét negálja. 


Mi lenne, ha a lista minden eleméhez complex(2, 3)-at akarnánk hozzáadni? Ezt könnyen 
megtehetjük: 


void add23(complex£ c) 


( 
c 47 complex(2,39; 


J 


void g(vectorccomplexzk aa, listccomplexzk ID 


( 
for. each(aa.beginO, aa.endO, add23); 


for. eachdl.beginO,II.endO, add239; 


J 


Hogyan tudnánk egy olyan függvényt írni, melyet többször meghívva egy-egy tetszőleges 
értéket adhatunk az elemekhez? Olyasmire van szükségünk, aminek megadhatjuk a kívánt 
értéket és utána ezt az értéket használja fel minden hívásnál. Ez a függvényeknek nem ter- 
mészetes tulajdonsága. Jellemző megoldásként valahova a függvényt körülvevő környezet- 
be helyezve adjuk át az értéket, ami nem , tiszta" megoldás. Viszont írhatunk egy osztályt, 
amely a megfelelő módon működik: 


class Add ( 
complex val; 

bublic: 
Add(complex c) f val - c; ? // az érték mentése 
Add(double r, double i) f val - complex(r, 1; ) 


void operatorO(complexát c) const f c 4- val; ) / a paraméter növelése az értékkel 
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Egy Add osztályú objektum kezdőértékének egy komplex számot adunk, majd a ( ) műve- 
letet végrehajtatva ezt a számot hozzáadjuk a paraméterhez: 


void h(vectorccomplexzk aa, listccomplexzk Il, complex 2) 


f 
for. each(aa.beginO, aa.endO, Add(2, 319; 
for. each(ll.beginO, II.endO, Add(2); 


J 


Ez a tömb minden eleméhez complex(2, 37-at fog adni, a lista elemeihez pedig z-t. Vegyük 
észre, hogy Add(2) egy olyan objektumot hoz létre, amelyet aztán a for. each ismételten fel- 
használ. Nem egyszerűen egy egyszer vagy többször meghívott függvényről van szó. 
A többször meghívott függvény az Add(2) operatorOO függvénye. 


Mindez azért működik, mert a for. each egy sablon (template), amely a ( ) műveletet alkal- 
mazza a harmadik paraméterére, anélkül, hogy törődne vele, mi is igazából a harmadik 
paraméter: 


templatecxclass Iter, class Fct- Fct for. each(iter b, Iter e, Fct f) 


while (b !- e) JGbra); 
return f; 


J 


Első pillantásra ez a módszer furcsának tűnhet, de egyszerű, hatékony, és nagyon hasznos 
(ásd §3.8.5, §18.4). 


Az operatorO0 további népszerű alkalmazásai a részláncok képzésére vagy több dimenzi- 
ós tömbök indexelésére (422.4.5) való használat. 


Az operatorOO-nak tagfüggvénynek kell lennie. 


11.10. Indirekció 


A -5 indirekció ( hivatkozástalanítás", dereferencing) operátort egyparaméterű, utótagként 
használt operátorként definiálhatjuk. Legyen adott egy osztály: 


class Ptr ( 
24 ta 
X" operator-2O; 


); 
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Ekkor a Ptr osztályú objektumokat az X osztály tagjainak elérésére használhatjuk, a muta- 
tókhoz nagyon hasonló módon: 


void (Ptr p) 


( 
b-em - 7; // (p.oberator-20)-2m - 7 


J 


A p objektumnak a p.oberator-20 mutatóvá való átalakítása nem függ attól, hogy milyen m 
tagra mutat. Az operator-20 ebben az értelemben egyoperandusú utótag-operátor, formai 
követelményei viszont nem újak, így a tagnevet ki kell írni utána: 


void e(Ptr p) 

( 
X- gi —- p-; // szintaktikus hiba 
X" g2 - p.operator-20; // rendben 


) 
A -20 operátor túlterhelésének fő alkalmazása az okos vagy intelligens mutató (smart po- 
inter) típusok létrehozása, azaz olyan objektumoké, amelyek mutatóként viselkednek, de 
ráadásul valamilyen tennivalót végeznek, valahányszor egy objektumot érnek el rajtuk ke- 
resztül. Például létrehozhatunk egy Rec pbtr osztályt, amellyel a lemezen tárolt Rec osztályú 
objektumok érhetőek el. A Rec ptir konstruktora egy nevet vár, melynek segítségével a ke- 
resett objektum a lemezen megkereshető, a Rec pbtr::operator-20 függvény a memóriába 
tölti az objektumot, amikor azt a Rec btr-en keresztül el akarjuk érni, a Rec ptr destruktora 
pedig szükség esetén a megváltozott objektumot a lemezre írja: 


class Rec ptr ( 
const char"? identifier; 
Rec:" in core address; 
ATS 

bublic: 
Rec ptr(const char" p) : identifier(p), in core address(0) ( ) 
-Rec ptrO ( write to disk(in core address,identifier); ) 
Rec?" operator-20; 

3; 

Rec?" Rec ptr::oberator-20 

( 
if (in core address -- 0) in core address - read from disk(identifier); 
return in core address; 
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A Rec ptr-t így használhatjuk: 


struct Rec f( // a Rec típus, amire Rec ptr mutat 
string name; 
77 eső 

J; 

void update(const char"? s) 

f 
Rec ptr p(59; // Rec ptr előállítása s-ből 
b--name - "Roscoe"; // s módosítása; ha szükséges, először beolvassa a lemezről 
JAS 

j 


Természetesen az igazi Rec ptr egy sablon lenne, a Rec típus pedig paraméter. Egy valósá- 
gos program hibakezelést is tartalmazna és kevésbé naív módon kezelné a lemezt. 


Közönséges mutatók esetében a -- használata egyenértékű az egyváltozós " és / / haszná- 
latával. Ha adott egy típus: 


Y" p; 
akkor teljesül a következő: 
bem -- Cp).m -- plf0l.m 


Ahogy már megszokhattuk, a felhasználói operátorokra nézve ez nem biztosított. Szükség 
esetén persze gondoskodhatunk erről: 


class Ptr.to Y( 

Yt p; 
pbublic: 

Y" operator-:0 f return px; ) 

Yk operator? ( return ?p; ) 

Y£k operatorf Int i) f return plil; ) 
j; 


Ha egy osztályban több ilyen operátort határozunk meg, akkor tanácsos lehet ezt úgy ten- 
ni, hogy a fenti egyenértékűség teljesüljön, ugyanúgy, mint ahogy -4-x és xt-7 is jó, ha 
xzxi1 1-gyel azonos hatással jár, ha x egy olyan osztályú változó, amelyben a -4-, 4-—, 4 mű- 
veletek értelmezettek. 
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A -- operátor túlterhelhetősége nem csak kis különlegesség, hanem érdekes programok 
egy osztálya számára fontos is, azon oknál fogva, hogy az indirekció (dereferencing) kulcs- 
fogalom, a -2 operátor túlterhelése pedig tiszta, közvetlen és hatékony módja annak egy 
programban való megjelenítésére. A bejárók (iterátorok) (19. fejeze) jellemző és lényegi 
példát adnak erre. A -- operátor másik haszna, hogy korlátozott, de hasznos módon lehe- 


tővé teszi a C44 nyelvben a delegációt (424.2.4). 


Az operator-: tagfüggvény kell, hogy legyen. Csak úgy használható, ha mutatót vagy olyan 
típust ad vissza, amelyre a -- alkalmazható. Ha egy sablon osztály számára adjuk meg, sok- 
szor előfordul, hogy nem is kerül tényleges felhasználásra, ezért ésszerű e megszorítás el- 
lenőrzését a tényleges használatig elhalasztani. 


11.11. Növelés és csökkentés 


Amint a programozó kitalál egy , intelligens mutatót", sokszor dönt úgy, hogy ehhez a 4-4 
növelő (increment) és -- csökkentő (decrement) művelet is hozzátartozik, a beépített típu- 
sokra értelmezett növelés és csökkentés mintájára. Ez különösen nyilvánvaló és szükséges 
olyankor, amikor a cél egy közönséges mutatónak egy okosra való kicserélése, amely azo- 
nos jelentés mellett csak némi futási idejű hiba-ellenőrzéssel van kiegészítve. Vegyük pél- 
dául az alábbi — egyébként problematikus — hagyományos programot: 


void fI(T a) // hagyományos használat 
( 
T [200]; 
Tt p - kulol; 
ba 
kp - d; // hoppá: p" tartományon kívüli és nem kaptuk el 
tAD; 
xp - d; // rendben 


A p mutatót ki szeretnénk cserélni valamilyen Ptr. to Tosztályú objektumra, amelyre csak ak- 
kor tudjuk alkalmazni az indirekció operátort, ha tényleg egy objektumra mutat. Azt is el sze- 
retnénk érni, hogy b-t csak úgy lehessen növelni vagy csökkenteni, ha tömbön belüli objek- 
tumra mutat, még a növelés vagy csökkentés hatására is. Valami ilyesmit szeretnénk tehát: 


class Ptr.to T( 
Ms 


J; 
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void f2(T a) // ellenőrzött 
t 
T v[200)7; 
Ptr. to T p(kuIOJ, v, 2009; 
D- 
kp — a; // futási idejű hiba: p" tartományon kívüli 
rap; 
kp — a; // rendben 
j 


A növelő és csökkentő operátorok az egyetlenek a Csi nyelv operátorai között, amelyek 
előtagként (prefix) és utótagként (postfix) egyaránt használhatók. Ezért a Ptr. to T típus 
számára mindkét fajta növelő és csökkentő operátort definiálnunk kell: 


class Ptir.to Tf 


Tt p; 
T" array; 
int size; 

bublic: 
Ptr.to IT" p, T" v, int 5); // csatolás s méretű v tömbhöz, a kezdőérték p 
Ptr.to MT" p); // csatolás önálló objektumhoz, a kezdőérték p 
Ptr.to Tk operatort4O; // előtag 
Ptr. to T operatortt(inD); // utótag 
Ptr. to TK operator-—O); // előtag 
Ptr. to T operator--(int); // utótag 
Ik operator? O; // előtag 


75 


Az int paraméterrel jelezzük a 4-4 utótagként való alkalmazását. Magát az int-et nem hasz- 
náljuk, csak ál-paraméter, amely az elő- és utótagként való használat között tesz különbsé- 
get. Könnyen megjegyezhetjük, melyik melyik, ha arra gondolunk, hogy a többi (aritmeti- 
kai és logikai) egy paraméterű operátorhoz hasonlóan az ál-paraméter nélküli -4- és -- az 
előtagként, a paraméteres változat a , furcsa" utótagként való működéshez kell. 


A Prt to T osztályt használva a példa egyenértékű az alábbival: 


void J3(T a) // ellenőrzött 
( 
T v[200]; 
Ptr. to T p(£kuIOJ,v, 2009; 
b.operator--(0); 
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b.oberatort) -a; — // futási idejű hiba: p" tartományon kívüli 
b.oberatorttO; 


b.oberator? — a; // rendben 


j 


A Prt to Tosztály kiegészítése gyakorlatnak marad (§11.14[19]. Átdolgozása olyan sablon- 
ná, amely kivételeket is használ a futási időben fellépő hibák jelzésére, egy másik gyakor- 
lat (§14.12I[12D. A §13.6.3 egy mutatósablont mutat be, amely öröklődés használata mellett 
is jól működik. 


11.12. Egy karakterlánc osztály 


Íme a String osztály egy valóságosabb változata, amely a céljainknak még éppen megfelel. 
Ez a karakterlánc-osztály támogatja az érték szerinti működést (value semantics, érték-sze- 
mantika), a karakteríró és -olvasó műveleteket, az ellenőrzött és ellenőrizetlen elérést, az 
adatfolyam ki- és bemenetet, a karakterliterálokat, az egyenlőségvizsgáló és összefűző mű- 
veleteket. A karakterláncokat C stílusú, nullával lezárt karaktertömbként tárolja, a másolások 
számának csökkentésére pedig hivatkozásszámlálót használ. Egy többet tudó és/vagy több 
szolgáltatást nyújtó szring osztály írása jó gyakorlat (§11.14[7-120. Ha megvagyunk vele, el- 
dobhatjuk a gyakorlatainkat és használhatjuk a standard könyvtárbeli string-et (20. fejeze0. 


Az én majdnem valóságos String osztályom három segédosztályt használ: az Srep-et, hogy 
több azonos értékű String is használhassa ugyanazt az eltárolt adatot, ha azonos az értékük; 
a Range-et az értéktartomány-megsértési hibákat jelző kivételek kiváltásához; és a Cref-et, 
hogy egy írás és olvasás között különbséget tevő index-operátort támogasson: 


class String ( 


struct Srep; // adatábrázolás 
Srep "rep; 

bublic: 
class Crejf; // referencia char-ra 
class Range [ ? ; // kivételkezeléshez 


V/Y 
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A többi taghoz hasonlóan a tagosztályokat (member class, amit gyakran hívnak beágyazott 


osztálynak, nested class-nak is) deklarálhatjuk az osztályban, majd később kifejthetjük: 


struct String::Srep ( 


char"? s; // mutató az elemekre 
int Sz; // karakterek száma 
int n; // hivatkozásszámláló 


Srep(int nsz, const char? p) 


t 
n 7 1; 
sz — nsz; 
s - new charisza 1]; // hely a lezáró nulla számára is 
strecpy(s,P); 
J 


-SrepO f deletel[ ]J s; ? 


Srep? get own copyO // másolás, ha szükséges 
t 

if (n--1) return this; 

n-; 


return new Srep(sz, 5); 


j 
void assign(int nsz, const char? p) 
f 
if (sz !- nsz) ( 
deletel J s; 
SZ — nsz; 
s - new charisz4 1]; 
j 
strcpy(s p); 
J 
private: // a másolás megakadályozása 
Srep(const Srepő ); 


Srepk operator—-(const Srepé ); 
j; 


A String osztálynak megvannak a szokásos konstruktorai, destruktora és értékadó műve- 
letei is: 


class String ( 
7 éa 
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StringO; // a — 
String(const char"); 7 x 7 "abc" 
String(const String ); // x - másik karakterlánc 


Stringk operator-(const char ?); 
Stringáz oberator—(const Stringf£ ); 
-StringO; 


Lise 


A String osztály érték szerint működik, azaz egy s1-s2 értékadás után s7 és 52 két teljesen 
különböző karakterlánc lesz, vagyis ha később az egyiket módosítjuk, akkor annak nem 
lesz hatása a másikra. A másik megoldás az lenne, ha a Sfring osztály mutatókkal dolgoz- 
na. Ekkor az s71-s2 értékadás után s2 megváltoztatása s17-et is érintené. Ha egy osztálynak 
megvannak a hagyományos. aritmetikai műveletei, mint a komplex számokkal, vek- 
torokkal, mátrixokkal, karakterláncokkal végzettek, én előnyben részesítem az érték szerin- 
ti működést. Ahhoz viszont, hogy ennek támogatása ne kerüljön túl sokba, a Szring-et le- 
íróként ábrázolom, amely az adatábrázolásra mutat, amit csak szükség esetén kell másolni: 


String::StringO // az alapértelmezett érték egy üres karakterlánc 


( 


J 


rep - new Srep(O, "; 


String::String(const Stringí x) // másoló konstruktor 
( 
x.rep-ontt; 
rep - x.rep; // az ábrázolás megosztása 


J 


String::-StringO 


( 
if (--rep-2n -—- 0) delete rep; 
j 
String String::oberator—(const Stringít x) // másoló értékadás 
( 
x.repontt; // védelem az "st -— st" ellen 
if (-rep-2n -- 0) delete rep; 
rep - x.rep; // az ábrázolás megosztása 


return "this; 


A const char?" paraméterű ál-másoló műveletek bevezetésével a karakterliterálokat is meg- 
engedjük: 
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String::String(const char? 5) 


f 
rep - new Srep(strlen(5), 59; 
J 
Stringék String::oberator—-(const char" s) 
f 
if (repcn -- 1) // Srep újrahasznosítása 
rep-2assign(strlen(5), 59; 
else ( // új Srep használata 
rep-2n-; 
rep - new Srep(strlen(5), 59; 
j 
return "this; 
J 


Az egyes karakterláncokat elérő operátorok megtervezése nehéz, mert az ideális megoldás 
az lenne, ha ezek a szokásos jelölést (azaz a / /D használnák, a lehető leghatékonyabbak 
lennének és a paraméter értékét is ellenőriznék. Sajnos, ez a három követelmény nem tel- 
jesíthető egyszerre. Én úgy készítettem el az osztályt, hogy hatékony ellenőrizetlen műve- 
leteket adtam meg (egy kicsit kényelmetlenebb jelöléssel), illetve kevésbé hatékony ellen- 
őrzött eljárásokat (a hagyományos jelöléssel]: 


class String ( 
71 ee 


void check(int i) const f if (20 1 1 rep-3sz-i) throw RangeO; ) 


char readGint i) const ( return rep-slil; ) 
void write(int i, char c) ( rep-rep-2get own copyO; rep-sl[il-c; ) 


Cref operatorf [Gint i) f check(; return CrefCthis, 1); ) 
char operatorf [int í) const ( check(i; return rep-oslil; ) 


int sizeO const f return rep--sz; ) 


lesza 


Az ötlet az, hogy a hagyományos / / jelöléssel az ellenőrzött elérés legyen biztosított a kö- 
zönséges felhasználás számára, de a felhasználónak legyen módja egyszerre végignézni 
a teljes tartományt és a gyorsabb, ellenőrizetlen elérést használni: 
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int hash(const Stringft 5) 


( 
int h — s.read(0); 
const int max — s.sizeO; 
for (int i -— 1; igjmax; it4) h N- s.read(5P1;  // ellenőrzés nélküli hozzáférés s-hez 
return h; 


Nehéz dolog egy operátort, például a / /t úgy meghatározni, hogy az az író és az olvasó jel- 
legű hozzáférést is támogassa, ha nem fogadható el az a megoldás, hogy egyszerűen egy 
referenciát adunk vissza, amit aztán a felhasználó kedve szerint felhasználhat. Itt például ez 
nem lehetséges, mert a Szring-et úgy határoztam meg, hogy az egyes értékadással, 
paraméter-átadással stb. megadott értékű String-ek ugyanazt a belső ábrázolást használják, 
míg az egyik String-et ténylegesen nem írják: az érték másolása csak ekkor történik meg. 
Ezt a módszert általában íráskori másolásnak vagy , másolás íráskor"-nak (copy-on-write) 
hívják. A tényleges másolást a String::get own copyO végzi. 


Abból a célból, hogy az elérő függvényeket helyben kifejtve (inline) lehessen fordíttatni, 
olyan helyre kell elhelyezni definiciójukat, ahonnan az Srep osztályé elérhető. Tehát vagy 


az Srep-et kell a String osztályon belül megadni, vagy pedig az elérő függvényeket kell 
inline-ként meghatározni a String-en kívül és az String::Srep után (411.14l2D. 


Megkülönböztetendő az írást és az olvasást, a String::operatorf JO egy Cref-et ad vissza, ha 
nem const objektumra hívták meg. A Crefúgy viselkedik, mint a chark, azzal a különbség- 
gel, hogy írásakor meghívja a Szring::Sref::get own copyO-t: 


class String::Cref f // hivatkozás sl[i/-re 
friend class String; 
Stringét s; 
int í; 
Cref(Stringé ss, int ii) : s(ss), i(ii) ( ? 
bublic: 
operator charO const f return s.read(i; ) // érték kijelölése 
void operator—(char c) f s.write(i, c); ) // érték módosítása 
5 
Például: 


void (String s, const Stringk r) 

( 
char c1 — s/1]: // c1 - s.operatorf ((1.operator charO 
s[17 — tc) // s.operatorf K(1).operator—( c) 
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char c2 — 11]; // c2 - r.operatorf (1) 
[1] - d; // hiba: char értékadás, r.operatorf I(1) - d" 


J 


Vegyük észre, hogy egy nem const objektumra az s.operatorf (1) értéke Crejf(s, 1) lesz. 
Ahhoz, hogy teljessé tegyük a Sztring osztályt, meghatározunk még egy sor hasznos függvényt: 


class String 
MEYE 


Stringk operatort—(const Stringf ); 
Stringk operatort4-(const char"); 


friend ostreamég operators(ostreamdg, const String ); 
friend istream£ operator:?(istreamd£, String ); 


friend bool operator-—(const Stringét x, const char" s) 
f return strcemp(x.rep-:s, s) -— O; ) 


friend bool operator-—(const Stringét x, const Stringf y) 
€ return stremp(x.rep-:s, y.rep-2s) -— O; ) 


friend bool operator!1—(const Stringét x, const char" s) 
€ return strcemp(x.rep--s, s) !- O; ) 


friend bool operator!1—(const Stringdt x, const Stringkg y) 
f return stremp(x.rep-:s, y.rep-25) !- O; ) 


); 


String operatort(const Stringét, const Stringfk ); 
String operatort(const Stringk, const char"); 


Hely-megtakarítás céljából a ki- és bemeneti operátorokat, illetve az összefűzést meghagy- 


tam gyakorlatnak. 
A főprogram pusztán egy kissé megdolgoztatja a String operátorokat: 
String (String a, String b) 
al2] - Xx; 


char c — b[3]; 
cout c£ "Az f-ben: "zzasz!Iszcbcc!Iczccc Mp; 


return b; 
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int mainŐ 


( 


String Xx, y; 

cout c£ "Adjon meg két karakterláncotNm "; 

cín22x 55 y; 

cout 22 "Bemenet: " 2 x 2! czyecc Mm); 

String z — Xx; 

y — JOGI; 

if (x 1- 2) cout cz "Az x sérült Nm"; 

xf0] - 

if (x -—— 2) cout c£ "Az írás nem sikerültNm"; 

cout c£ "Kilépés: "cc xcc!Icgycc!Icszaec Mm; 


Ebből a String osztályból még hiányoznak fontosnak vagy akár alapvetőnek tekinthető dol- 
gok, például nincs az értéket C stílusú adatként visszaadó művelet (11.14[10], 20. fejezeD. 


11.13. 


[1] 


[2] 
[3] 


[4] 


[5] 


[6] 


[7] 


[8] 


[91 


Tanácsok 


Operátorokat elsősorban azért adjunk meg, hogy a szokásos használati módot 
támogassuk. §11.1. 

Nagy operandusok esetében használjunk const referencia paramétereket. §11.6. 
Nagy értékeket adó eredményeknél fontoljuk meg az eredmény-visszaadás opti- 
malizálását. 11.6. 

Hagyatkozzunk az alapértelmezett másoló műveletekre, ha azok megfelelőek az 
osztályunk számára. 11.3.4. 

Bíráljuk felül vagy tiltsuk meg az alapértelmezett másolást, ha az egy adott típus 
számára nem megfelelő. 11.2.2. 

Ha egy függvénynek szüksége van az adatábrázolás elérésére, inkább tagfügg- 
vény legyen. 11.5.2. 

Ha egy függvénynek nincs szüksége az adatábrázolás elérésére, inkább ne 
legyen tagfüggvény. 11.5.2. 

Használjunk névteret, hogy a segédfüggvényeket osztályukhoz rendeljük. 
§11.2.4. 

Szimmetrikus műveletekre használjunk nem tag függvényeket. §11.3.2. 


[10] Többdimenziós tömb indexelésére használjunk 0-t. §11.9. 
[11] Az egyetlen , méret" paraméterű konstruktorok legyenek explicit-ek. §11.7.1. 
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[12] Általános célra használjuk a szabványos string-et (20. fejezet), ne a gyakorlatok 
megoldása révén kapott saját változatot. §11.12. 

[13] Legyünk óvatosak az automatikus konverziók bevezetésekor. §11.4. 

[14] Bal oldali operandusként balértéket váró műveleteket tagfüggvényekkel valósít- 
sunk meg. §11.3.5. 


11.14. Gyakorlatok 


1. (2) Milyen konverziókat használunk az alábbi program egyes kifejezéseiben: 


struct X ( 
int í; 
X XGNnD; 
operatort (int); 


ij 


structY ( 
int í; 
Y(XI; 
Y operator4 (XX); 
operator intO; 


581 


extern X operator" (X, Y); 
extern int fC); 


XXx7 [; 
Yy-—x; 
inti—- 2 


int mainO 


í 
id 10; yt 10 yt 109; 
xtyrti xtxdri fOD; 
JOD; It3 106 4 y; 

) 


Módosítsuk a programot úgy, hogy futás közben kiírjon minden megengedett 
kifejezést. 
2. (2) Fejezzük be és teszteljük a §11.12-beli Szring osztályt. 
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. 2) Definiáljuk az INT osztályt, amely pontosan úgy viselkedik, mint egy int. 


(Segítség: definiáljuk az INT::operator intO-et). 


. C1 Definiáljuk a RINT osztályt, amely pontosan úgy viselkedik, mint egy int, 


azzal a különbséggel, hogy csak a következő műveletek engedélyezettek: (egy 
és két paraméterű) -, (egy és két paraméterű) -, ", / és 96. (Segítség: ne 
definiáljuk a RINT::operator int0-e0. 


. C3) Definiáljuk a LINT osztályt, amely pontosan úgy viselkedik, mint a RINT;, de 


legalább 64 bites pontosságú. 


. 4) Definiáljunk egy tetszőleges pontosságú aritmetikát támogató osztályt. 


Teszteljük az 1000 faktoriálisának kiszámíttatásával. (Segítség: a String osztályé- 
hoz hasonló társzervezésre lesz szükség.) 


. 2) Határozzunk meg a String osztály számára egy külső bejárót (iterátor0: 


class String iter f 
// hivatkozás karakterláncra és annak elemére 
bublic: 
String iter(Stringőt 5); // bejáró s számára 
chark nextO; // hivatkozás a következő elemre 


// igény szerint további műveletek 


Hasonlítsuk ezt össze hasznosság, stílus és hatékonyság szempontjából a String 
egy belső bejárójával. (Vagyis adott egy kurrens elemünk a String-ben, és a vele 
kapcsolatos műveletek.) 


. 1.5) A O operátor túlterhelésével határozzunk meg egy részlánc-műveletet 


egy karakterlánc-osztály számára. Milyen más műveletet szeretnénk egy karak- 
terláncon végezni? 


. 03) Tervezzük meg úgy a String osztályt, hogy a részlánc-operátort egy érték- 


adás bal oldalán is fel lehessen használni. Először egy olyan változatot írjunk, 
amelyiknél egy részláncot egy azonos hosszúságú teljes karakterláncra lehet 
cserélni, aztán egy olyat, amelyiknél eltérőre. 


10.02) Definiáljuk a String osztály számára az értéket C stílusú adatként visszaadó 


műveletet. Vitassuk meg annak előnyeit és hátrányait, hogy ez egy konverziós 
operátor. Vitassuk meg a C stílusú adat számára szükséges memória lefoglalásá- 
nak különféle módjait. 


11.C€2.5) Tervezzünk és készítsünk egy egyszerű reguláris kifejezés illesztő eszközt 


a String osztály számára. 


12.C1.5) Módosítsuk úgy a §11.14I11]-beli eszközt, hogy az működjön a standard 


könyvtárbeli szring-gel. A string definícióját nem változtathatjuk meg. 
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13. (2) Írjunk egy programot, amit operátor-túlterheléssel és a makrók használatá- 
val olvashatatlanná teszünk. Egy ötlet: határozzuk meg -- -t úgy az INT-ekre, 
hogy - -t jelentsen és fordítva. Ezután egy makróval határozzuk meg úgy az int- 
et, hogy INT-et jelentsen. Bíráljuk felül a népszerű" függvényeket referencia 
típusú paramétereket használó függvényekként. Néhány félrevezető megjegy- 
zéssel is nagy zavart lehet kelteni. 

14.33) Cseréljük ki egy barátunkkal a §11.14113] feladatra adott megoldásunkat, és 
próbáljuk meg futtatása nélkül kideríteni, mit csinál. A gyakorlat végére meg 
fogjuk tanulni, hogy mit ne tegyünk többé. 

15. (2) Definiáljuk a Vec4 típust, mint négy //loat-ból álló vektort. Definiáljuk a / / 
műveletet. Adjuk meg a 4, -, ?, / —, 4, 4-, -—, £— és /- műveleteket a vektorok 
és float-ok együttes használatára. 

16. C3) Definiáljuk a Matá4 típust, mint négy Vecá-ből álló vektort. Definiáljuk a / / 
műveletet, mint ami Vecf£-et ad vissza, ha a Matá-re alkalmazzuk. Adjuk meg 
a szokásos mátrix-műveleteket. Készítsünk függvényt, amely a Gauss-féle kikü- 
szöbölés módszerét alkalmazza egy Matí-rre. 

17.(C"2) Definiáljunk egy Vector típust, amely a Vecá-hez hasonlít, de 
Vector:: Vector(int) konstruktorának paraméterként megadhatjuk a méretet. 

18. €3) Definiáljunk egy Matrix típust, amely a Matá£-hez hasonlít, de 
Matrix:: Matrix(int, int) konstruktorának paraméterként megadhatjuk 
a dimenziókat. 

19. €2) Fejezzük be a §11.11 pont Pir. to 7 osztályát és ellenőrizzük. Legyenek 
meg legalább a ", -2, -, 4-4 és -- műveletek. Ne okozzunk futási idejű hibát, 
csak ha egy hibás mutatót ténylegesen felhasználnak. 

20.C"1) Adott két struktúra: 





struct S ( int x, y; ); 
struct T ( char? p; char? ag; ); 


írjunk egy C osztályt, melynek segítségével majdnem úgy használhatjuk vala- 
mely Sés 7 x-ét és p-jét, mint ha x és p C tagja lenne. 
21.C1.5) Definiáljuk az Index osztályt a mypow(double, Index) hatványozó függ- 
vény kitevője számára. Találjunk módot arra, hogy 2""/7 meghívja mybou(2, D-t. 
22.(€"2) Definiáljuk az Imaginary osztályt képzetes számok ábrázolására. 
Definiáljuk a Complex osztályt ennek alapján. Készítsük el az alapvető 
aritmetikai műveleteket. 
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Származtatott osztályok 


, Ne szaporítsuk az 
objektumokat, 

ha nem szükséges." 
(W. Occam) 


Fogalmak és osztályok s Származtatott osztályok s Tagfüggvények s Létrehozás és meg- 
semmisítés s Osztályhierarchiák s Típusmezők e Virtuális függvények s Absztrakt osztá- 
lyok e Hagyományos osztályhierarchiák e Absztrakt osztályok mint felületek s Az objektu- 
mok létrehozásának adott helyre korlátozása e Absztrakt osztályok és osztályhierarchiák 
e Tanácsok s Gyakorlatok 


12.1. Bevezetés 


A C45 a Simula nyelvtől kölcsönözte az osztály, mint felhasználói típus, illetve az osztályhi- 
erarchia fogalmát, valamint a rendszertervezés azon elvét, hogy a programban használt fo- 
galmak modellezésére osztályokat használjon. A Ct- nyújtotta nyelvi szerkezetek közvet- 
lenül támogatják ezeket a tervezési elveket. Megfordítva is igaz: akkor használjuk a C4- 
nyelvet hatékonyan, ha a nyelvi lehetőségeket a tervezési elvek támogatására használjuk. 
Aki a nyelvi elemeket csak a hagyományosabb programozás jelölésbeli alátámasztására 
használja, a C-t valódi erősségének használatáról mond le. 
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Egy fogalom sohasem önmagában létezik, hanem más fogalmakkal együtt és erejének egy 
részét is a rokon fogalmakkal való kapcsolatból meríti. Próbáljuk csak megmagyarázni, mi 
az, hogy autó. Hamarosan bevezetjük a következő fogalmakat: kerék, motor, vezető, gya- 
logos, teherautó, mentők, utak, olaj, gyorshajtás, bírság, motel stb. Minthogy a fogalmakat 
osztályokként ábrázoljuk, felmerül a kérdés: hogyan ábrázoljuk a fogalmak közötti kapcso- 
latokat? Persze tetszőleges kapcsolatot egy programozási nyelvben nem tudunk közvetle- 
nül kifejezni. De ha tudnánk, akkor sem akarnánk, hiszen osztályainkat a mindennapi 
életben használt fogalmaknál szűkebben és precízebben akarjuk meghatározni. A származ- 
tatott osztály fogalma és a vele kapcsolatos nyelvi eljárások célja a viszonyok kifejezése, 
azaz hogy kifejezzék, mi a közös az osztályokban. A kör és a háromszög fogalmában pél- 
dául közös, hogy mindkettő síkgörbe-alakzat, így a Circle (Kör) és Triangle (Háromszög) 
osztályokat úgy írhatjuk le, hogy pontosan meghatározott (explicit) módon megmondjuk, 
hogy a Shape (Alakzat) osztály a közös bennük. Ha egy programban úgy szerepeltetünk kö- 
röket és háromszögeket, hogy nem vonjuk be a síkidom fogalmát, akkor valami lényegeset 
mulasztunk el. Ez a fejezet azt feszegeti, mi következik ebből az egyszerű elvből — ami va- 
lójában az általában objektumorientáltnak nevezett programozási elv alapja. 


A nyelvi lehetőségek és módszerek bemutatása az egyszerűtől és konkréttól a bonyolul- 
tabb, kifinomultabb, elvontabb felé halad. Sokak számára ez a megszokottól a kevésbé is- 
mert felé való haladást is fogja jelenti. De ez nem csupán egyszerű utazás a , régi, rossz mód- 
szerektől" az ,egyedüli igaz út" felé. Amikor rámutatok egy megközelítés korlátaira, hogy 
a programozót az új felé tereljem, mindig adott problémák kapcsán teszem; más problémák 
kapcsán vagy más összefüggésben lehetséges, hogy a korábbi módszer alkalmazása a jobb 
választás. Használható programokat az itt tárgyalt módszerek mindegyikének felhasználá- 
sával írtak már. A cél az, hogy az olvasó megismerje az összes eljárást, hogy aztán okos és 
kiegyensúlyozott módon tudjon majd választani közülük, amikor igazi feladatokat kell 
megoldania. 


A fejezetben először az objektumorientált programozást támogató alapvető nyelvi eszközö- 
ket mutatom be, majd egy hosszabb példa kapcsán azt tárgyalom, hogyan lehet ezek alkal- 
mazásával jól szerkesztett programot írni. Az objektumorientált programozást támogató to- 
vábbi nyelvi eszközöket, például a többszörös öröklődést vagy a futási idejű típusazonosíi- 
tást a 15. fejezet tárgyalja. 
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12.2. Származtatott osztályok 


Vegyünk egy programot, amely egy cég dolgozóit kezeli. Egy efféle programban lehet egy 
ilyen adatszerkezet: 


struct Employee ( // alkalmazott 
string first name, family name; 
char middle initial; 
Date hiring date; 
short department; 
VZSEA 
j; 


Ezután , meghatározhatunk" egy főnököt is: 


struct Manager ( // főnök 
Employee emp; // a főnök mint alkalmazott 
setkEmployeet: group; // beosztottak 
short level; 
4 san 
j; 


A főnök egyben alkalmazott is, ezért az Embloyee (Alkalmazotb) adatokat a Manager (Fő- 
nök, vezető) objektum emp tagjában tároljuk. Ez nyilvánvaló lehet a programozó (különö- 
sen egy figyelmes programozó) számára, de a fordítóprogram és az egyéb eszközök sehon- 
nan nem fogják tudni, hogy a Manager egyben Employee is. Egy Manager? nem Employee" 
is egyben, így a kettő nem cserélhető fel. Egy Employee-ket tartalmazó listára nem vehetünk 
fel egy Manager-t a megfelelő kód megírása nélkül. Vagy típuskényszerítést kellene alkal- 
maznunk a Manager?"-ra, vagy az emp tag címét kellene az alkalmazottak listájára tennünk. 
Egyik megoldás sem elegáns és zavaró is lehet. A helyes megközelítés az, hogy kifejezetten 
megmondjuk, a Manager-ek egyben Employee-k is, csak további adatokat is tartalmaznak: 


struct Manager : public Employee f 
setkEmployee?: group; 
short level; 
117 

J; 


A Manager az Employee-ból származik, és fordítva, az Embloyee a Manager bázisosztálya. 
A Manager osztálynak megvannak azok a tagjai, amelyek az Employee-nek is (/irst name, 
department stb.) és ezekhez jönnek hozzá a saját tagok (group, level stb.). 
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A származtatást gyakran úgy ábrázolják grafikusan, hogy a származtatott osztályból egy nyi- 
lat rajzolnak a bázisosztály felé, jelezve, hogy a származtatott osztály a bázisosztályra hivat- 
kozik (és nem fordítva): 


Employee 


! 


Manager 


Általában úgy mondják, a származtatott osztály tulajdonságokat örököl a bázisosztálytól. 
Ennek alapján ezt a kapcsolatot öröklődésnek (öröklés, inheritance) is hívják. Az angol ki- 
fejezések a bázisposztályra és a származtatott osztályra: base class (vagy superclass), illet- 
ve derived class (subclass). Az utóbbi szóhasználat (superclass — főosztály, subclass — alosz- 
tály) azonban zavaró lehet, hiszen a származtatott osztály bizonyos értelemben , szélesebb" 
a bázisosztálynál, mivel annál több adatot tárol és több függvényt biztosít. 


A származtatás népszerű és hatékony megvalósítása a származtatott osztályú objektumot 


a bázisosztály olyan objektumaként ábrázolja, amely kiegészül a származtatott osztályra 
egyedileg jellemző adatokkal is: 


Emplyee: Manager: 








Jirst name first name 
Jamily name Jamily name 











group 
level 
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A Manager osztálynak az Employee-ból ilyen módon való származtatása a Manager típust 
az Employee altípusává teszi, így tehát mindenhol, ahol Employee objektum használható, 
egy Manager is megfelel. Most már készíthetünk egy listát az alkalmazottakról (Employee), 
akiknek egy része vezető beosztású (Manager): 


void (Manager m1, Employee e1) 


f 
listsEmployee?: elist; 
elistpush front(km1); 
elistpush front(ke1); 
Mé 

J 


Ne feledjük, egy Manager egyben Employee is, így egy Manager"-ot használhatunk 
Employee"-ként is. Az Employee viszont nem feltétlenül Manager, így Employee?-ot nem 
használhatunk Manager"-ként. Általában, ha egy Derived (származtatott) osztálynak egy 
Base (bázis) osztály nyilvános bázisosztálya (415.3), akkor egy Base? változó 
típuskényszerítés nélkül kaphat Derived" típusú értéket. A másik irányban (Base"-ról 
Derived"-ra) explicit konverzió szükséges: 


void ((Manager mm, Employee ee) 


( 
Employee? pe - kmm; // rendben: minden Manager egyben Employee is 
Manager? pm - £kee; // hiba: nem minden Employee főnök 
bmelevel - 2; // katasztrófa: ee nem rendelkezik level" taggal 
bm - static castkManager" (pe); // "nyers erővel": működik, mert pe 
// a Manager típusú mm-re mutat 
bpm- level — 2; // ez is jó: bpm a Manager típusú mm-re mutat, 
// amelynek van level" tagja 
j 


Vagyis mutatók és referenciák használatakor a származtatott osztály objektumait úgy kezel- 
hetjük, mint a bázisosztály objektumait. A másik irányban ez nem áll. A szatic cast és 
a dynamic cast használatát a §15.4.2 pont írja le. 


Egy osztály bázisosztályként való használata egyenértékű az osztály egy (névtelen) objek- 
tumának deklarálásával. Következésképpen egy osztályt csak akkor használhatunk bázis- 
osztályként, ha definiáltuk (§5.79: 
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class Employee; // csak deklaráció, nem definíció 


class Manager : public Employeef // hiba: Employee nem definiált 
Zé 


J; 


12.2.1. Tagfüggvények 


Az egyszerű adatszerkezetek — mint a Manager és az Employee — nem túl érdekesek és sok- 
szor nem is különösebben hasznosak. Az információt megfelelő típusként kell megadnunk, 
melyhez az elvégezhető műveletek is hozzátartoznak, és ezt úgy kell megtennünk, hogy 
közben nem kötődünk az adott ábrázoláshoz: 


class Employee f 
string first name, family name; 
char middle initial; 
Ms 
bublic: 
void printO const; 
string full nameO const 
( return first name 4 !! 4 middle initial 4 "! 4 family name; ) 


VE 


3; 
class Manager : public Employee ( 
szé; 
bublic: 
void printO const; 
Métee 


J; 
A származtatott osztályok tagfüggvényei ugyanúgy elérhetik a bázisosztály nyilvános 
(public) — és védett (protected, §15.3) — tagjait, mintha maguk vezették volna be azokat: 


void Manager: :printO) const 
( 


cout CZ "A keresett név " cz full nameO cz Mm; 


4 


J 


A származtatott osztály azonban nem éri el a bázisosztály privát (private) tagjait: 


void Manager: :printO) const 


( 


cout cz "A keresett név " cz family namescNn; — // hiba! 


Méz 
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A Manager::printO második változatát a fordító nem fogja lefordítani. A származtatott osz- 
tálynak nincs különleges engedélye a bázisosztály privát tagjainak elérésére, így 
a Manager::printO) számára a family name nem érhető el. 


Némelyek meglepődnek ezen, de gondoljuk el, mi lenne fordított esetben: ha a származta- 
tott osztály tagfüggvénye elérhetné a bázisosztály privát tagjait. A privát tag fogalma értel- 
metlenné válna azáltal, hogy a programozó hozzáférhetne az osztály privát részéhez egy 
osztályt származtatva belőle. Továbbá nem lehetne többé egy privát tag használatát a tag- 
és barát (friend) függvények átnézésével megkeresni. Az egész program minden forrásállo- 
mányát át kéne nézni: a származtatott osztályokat és azok függvényeit keresni, majd a szár- 
maztatott osztályokból származtatott további osztályokat és azok függvényeit és így tovább. 
Ez legjobb esetben is fárasztó és sokszor kivitelezhetetlen is. Ott, ahol ez elfogadható, in- 
kább védett (protected) és ne privát (private) tagokat használjunk. Egy védett tag a szár- 
maztatott osztályok számára olyan, mint egy nyilvános (public), a többiek számára azonban 
privátnak minősül (415.3). 


A legtisztább megoldás általában az, ha a származtatott osztály a bázisosztálynak csak 
a nyilvános tagjait használja: 


void Manager::printO) const 


( 
Employee::printO; // alkalmazottak adatainak kiírása 
cout cz level; // a főnökökre vonatkozó adatok kiírása 
7 éa 

J 


Vegyük észre, hogy a :: hatókör operátort kellett használni, mert a printO függvényt 
a Manager osztály újradefiniálja. A függvénynevek ilyen módon való újrafelhasználása igen 
általános. Ha óvatlanul ilyet írunk: 


void Manager::printO) const 


( 
printO; // hoppá! 


// a főnökökre vonatkozó adatok kiírása 


J 


a program váratlan módon újra és újra meg fogja hívni önmagát. 
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12.2.2. Konstruktorok és destruktorok 


Egyes származtatott osztályoknak konstruktorokra van szükségük. Ha a bázisosztálynak 
vannak ilyen függvényei, akkor az egyiket meg is kell hívni. Az alapértelmezett konstruk- 
torokat automatikusan is meghívhatjuk, de ha a bázisosztály minden konstruktora paramé- 
tert igényel, akkor a megfelelő konstruktort csak explicit módon lehet meghívni. Vegyük 
a következő példát: 


class Employee f 
string first name, family name; 
short department; 
11-őg 

bublic: 
Employee(const stringk n, int d); 
Ms 


2; 
class Manager : public Employee ( 
setkEmployeet: group; // beosztottak 
short level; 
ee 
bublic: 
Manage1(Cconst stringk n, int d, int lvD; 
Ve 


J; 
A bázisosztály konstruktora a származtatott osztály konstruktorának definiciójában kap pa- 
ramétereket. Ebből a szempontból a bázisosztály konstruktora úgy viselkedik, mintha 
a származtatott osztály tagja lenne (§10.4.09: 


Employee::Employee(const stringg n, int d) 

: family name(rn), department(d) // tagok kezdeti értékadása 
É 

Me 


j 


Manager::ManagerCconst stringét n, int d, int lul) 


: Employee(n, d), // a bázisosztály kezdeti értékadása 
level(lvD // tagok kezdeti értékadása 


lés 
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Egy származtatott osztály konstruktora csak a saját tagjai és a bázisosztály konstruktora szá- 


mára adhat meg kezdőértéket; a bázisosztály tagjainak nem: 


Manager:: ManagerCconst stringg n, int d, int WD 
: family name(n),  // hiba: family name nem deklarált a Manager osztályban 


department(d), // hiba: department nem deklarált a Manager osztályban 
level(IvD 
( 
MI 
J 


A fenti definíció három hibát tartalmaz: nem hívja meg az Employee konstruktorát, és két íz- 


ben is megpróbál közvetlenül kezdőértéket adni az Employee tagjainak. 

Az osztályba tartozó objektumok , alulról felfelé" épülnek fel; először a bázisosztály, aztán 
a tagok, végül maga a származtatott osztály. A megsemmisítés fordított sorrendben történik: 
először a származtatott osztály, aztán a tagok, végül a bázisosztály. A tagok a deklaráció sor- 
rendjében jönnek létre és fordított sorrendben semmisülnek meg (§10.4.6 és §15.2.4.1. 


12.2.3. Másolás 


Egy osztályba tartozó objektum másolását a másoló konstruktor és az értékadások határoz- 
zák meg (§10.4.4.D: 


class Employee f 
7 sz 
Employeek operator-(const Employeed ); 
Employee(const Employeed ); 


j; 
void (const Managerk m) 
( 
Employee e - m; // e létrehozása m Employee részéből 
e-m; // m Employee részének másolása e-be 
J 


Minthogy az Employee osztály másoló függvényei nem tudnak a Manager osztályról, a Ma- 
nager objektumnak csak az Employee része fog lemásolódni. Az objektumnak ez a , felsze- 
letelődése" (slicing), azaz a tény, hogy ekkor az objektumnak csak egy szelete másolódik 
le, meglepő lehet és hibákhoz vezethet. A felszeletelődés megakadályozása az egyik oka 
annak, hogy osztályhierarchiába tartozó objektumok esetében célszerűbb mutatókat és 
referenciákat használnunk. A hatékonysági megfontolások mellett további ok, hogy meg- 
őrizzük a többalakú (polimorfikus) viselkedést (42.5.4 és §12.2.0). 
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Jegyezzük meg, hogy ha nem határozunk meg másoló értékadó operátort, akkor a fordító- 
program fog létrehozni egyet. Ebből következik, hogy az értékadó operátorok nem örök- 
lődnek. (A konstruktorok soha.) 


12.2.4. Osztályhierarchiák 
Egy származtatott osztály lehet maga is bázisosztály: 


class Employee f /? ... "7 ); 
class Manager : public Employee ( /? ... "/ 3; 
class Director : public Manager f /£ ... "/ ); 


Az egymással kapcsolatban álló osztályok ilyen halmazát hagyományosan osztályhierarchiá- 
nak hívjuk. A hierarchia leggyakrabban fa szokott lenni, de lehet ennél általánosabb gráf is.: 


class Temporary € /§ ... "73; 

class Secretary : public Employee ( /? ... "/ 2; 

class Tsec : public Temporary, public Secretary ( / ... "/ ); 

class Consultant : public Temporary, public Manager f /? ... "/ ); 





Ábrával: 
Employee 
Temporary 
A 
Secretary Manager 
Tsec 
Consultant Director 


Vagyis ahogy a §415.2 pont részletesen elmagyarázza, a Cst nyelv képes az osztályoknak 
egy irányított körmentes gráfját kifejezni. 
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12.2.5. Típusmezők 


Ha a deklarációkban alkalmazott kényelmes rövidítésnél többre akarjuk használni az osztá- 
lyok származtatását, meg kell válaszolnunk a következő kérdést: ha adott egy Base?" muta- 
tó, akkor milyen származtatott osztályba tartozik az objektum, amelyre mutat? A problémá- 
nak négy alapvető megoldása van: 


Érjük el, hogy csak egyféle objektum jöhessen szóba (§2.7, 13. fejezet). 
Helyezzünk egy típusmezőt a bázisosztályba és a függvények ezt kérdezzék le. 
Használjuk a dynamic cast-ot (dinamikus típuskonverzió, §15.4.2, §15.4.59. 
Használjunk virtuális függvényeket (§2.5.5, §12.2.09. 


Boo E 


Bázisosztályra hivatkozó mutatókat gyakran használunk olyan tároló osztályokban 
(container class), mint a halmaz (seb), a vektor (vector) és a lista (/isD. Ekkor az első megol- 
dás homogén listákat, azaz azonos típusú objektumokat eredményez. A többi megoldás le- 
hetővé tesz heterogén listákat is, azaz olyanokat, ahol különböző típusú objektumok (vagy 
ilyenekre hivatkozó mutatók) lehetnek. A 3. megoldás a 2. megoldásnak a nyelv által támo- 
gatott változata, a 4. pedig a 2.-nak egyedi, típusbiztos átalakítása. Az 1. és a 4. megoldás 
párosításai különösen érdekesek és erősek; majdnem mindig világosabb kódot eredmé- 
nyeznek, mint a 2. vagy a 3. megoldás. 


Nézzünk meg először egy típusmezős megoldást, hogy lássuk, legtöbbször miért kerülen- 
dő. A , főnök -— alkalmazott" példát így írhatnánk át: 


struct Employee f 
enum Empl type f M, E ); 
Empl type type; 


EmployeeO : typéCE) ( ) 


string first name, family name; 
char middle initial; 


Date hiring date; 
short department; 
VAGY 
j; 
struct Manager : public Employee f 
ManagerO f type - M; ) 


setcEmployeet: group; // beosztottak 
short level; 


7. sza 
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Most már írhatunk egy függvényt, amely minden Employee-ről ki tudja írni az információt: 


void print employee(const Employee? e) 
( 
switch (e-:type) ( 
case Employee:: E: 
cout ££ e-x2family name cz M! ££ e-2department £z Mm; 


1.68 
break; 

case Employee::M: 

( cout ££ e-xfamily name cz M! ££ e-2department £z MM; 
Úyésa 


const Manager? p - static castcconst Manager?" r(e); 
cout CZ " szint " 22 p-2level cz Mi; 
1 ső 


break; 


jele] 


j 


Az alkalmazottak listája így írható ki: 


void print list(const listsxEmployee":£ elist) 


for (listsxEmployeet5::const iterator p — elist.beginO; p/-elist.endO; 41p) 
brint employeeCp); 
j 
Ez jól működik, különösen az egyetlen programozó által fenntartott kis programokban. 
Alapvető gyengéje, hogy az a feltétele, hogy a programozó a megfelelő (és a fordítóprog- 
ram által nem ellenőrizhető módon) kell, hogy kezelje a típusokat. A problémát általában 
súlyosbítja, hogy az olyan függvények, mint a print employee, a szóba jöhető osztályok kö- 
zös vonásait használják ki: 


void print employee(const Employee" e) 
( 
cout ££ e-x2family name cz M! ££ e-2department £z MM; 
se 
if (e-:type -—- Employee::M) f 
const Manager? p - static castéconst Manager?" r(e); 
cout CZ " szint " 22 p-2level cz Mi; 


Ma 


12. Származtatott osztályok 407 


Egy nagy függvényben, ahol sok származtatott típust kell kezelni, nehéz lehet az összes 
ilyen típusmező-ellenőrzést megtalálni. De ha megtaláltuk is, nehéz lehet megérteni, hogy 
mi is történik. Továbbá, ha a rendszer új Empbloyee-vel bővül, az összes fontos függvényt 
módosítani kell — vagyis az összes olyat, amelyik ellenőrzi a típusmezőt. Minden olyan 
függvényt meg kell vizsgálni, amelyiknek egy változtatás után szüksége lehet a típusmező 
ellenőrzésére. Ez azt jelenti, hogy hozzá kell férni a kritikus forráskódhoz és külön munkát 
jelent a változtatás utáni teszt is. A típuskényszerítés árulkodó jele annak, hogy javítani le- 
hetne a kódon. 


Vagyis a típusmezős megoldás hibákra ad lehetőséget és nehezen módosítható kódot ered- 
ményez. Ahogy a rendszer mérete nő, a probléma súlyosbodik, mert a típusmező alkal- 
mazása ellentmond a modularitás és az adatrejtés elvének. Minden típusmezőt használó 
függvénynek ismernie kell az összes olyan osztály ábrázolását (és megvalósításuk egyéb 
részleteit), amely a típusmezős osztály leszármazottja. 


Ezenkívül ha van egy olyan adat (például egy típusmező), amely minden származtatott osz- 
tályból elérhető, akkor a programozó hajlamos arra, hogy további ilyen mezőket hozzon 
létre. A közös bázisosztály így mindenféle , hasznos információk" gyűjteményévé válik. 
Ez aztán a bázisosztály és a származtatott osztályok megvalósításának legkevésbé kívánatos 
összefonódásához vezet. A tisztább felépítés és könnyebb módosíthatóság kedvéért a kü- 
lönálló dolgokat kezeljük külön, a kölcsönös függéseket pedig kerüljük el. 


12.2.6. Virtuális függvények 


A virtuális függvények azáltal kerülik el a típusmezős megoldás problémáit, hogy segítsé- 
gükkel a programozó olyan függvényeket deklarálhat a bázisosztályban, amelyeket a szár- 
maztatott osztályok felülbírálhatnak. A fordító- és betöltóprogram gondoskodik az objek- 
tumtípusok és az alkalmazott függvények összhangjáról: 


class Employee f 
string first name, family name; 
short department; 
Ha 
bublic: 
Employee(const string. name, int depW); 
virtual void print0 const; 
I: 
j; 
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A virtual kulcsszó azt jelenti, hogy a printO függvény felületként szolgál az ebben az osz- 
tályban definiált brintO függvényhez, illetve a származtatott osztályokban definiált brintO 
függvényekhez. Ha a származtatott osztályokban szerepelnek ilyenek, a fordítóprogram 
mindig az adott Employee objektumnak megfelelő függvényt fogja meghívni. 


Egy virtuális függvény akkor szolgálhat felületként a származtatott osztályokban definiált 
függvényekhez, ha azoknak ugyanolyan típusú paramétereik vannak, mint a bázisosztály- 
belinek, és a visszatérési érték is csak nagyon csekély mértékben különbözik (415.6.2). 
A virtuális tagfüggvényeket néha metódusoknak (method) is hívják. 


A virtuális függvényt mindig definiálnunk kell abban az osztályban, amelyben először 
deklaráltuk, hacsak nem tisztán virtuális (pure virtual) függvényként adtuk meg (412.39: 


void Employee::printO) const 
( 
cout 2 family name cz M! c£ department cz M; 


1 és 


J 


Virtuális függvényt akkor is használhatunk, ha osztályából nem is származtatunk további 
osztályt; ha pedig származtatunk, annak a függvényből nem kell feltétlenül saját változat. 
Osztály származtatásakor csak akkor írjunk egy megfelelő változatot a függvényből, ha va- 
lóban szükséges: 


class Manager : public Employee ( 
setskEmployeet2 group; 
short level; 
VES 
bublic: 
ManagerCconst stringíz name, int dept, int lv]D; 
void printO const; 
VSZE 


J; 
void Manager: :printO) const 
( 
Employee::printO; 
cout cz Miszint " cz level cz MM; 


Ms 
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A származtatott osztály azonos nevű és azonos típusú paraméterekkel bíró függvénye feltl- 
írja vagy felülbírálja Coverride) a virtuális függvény bázisosztálybeli változatát. Hacsak 
közvetlen módon meg nem mondjuk, hogy a virtuális függvény melyik változatát akarjuk 
használni — mint az Employee::printO hívásnál —, az objektumhoz leginkább illő felülíró 
függvény lesz meghívva. 


A globális print employeeO függvény (§12.2.5) szükségtelen, mert a helyébe a brintO tag- 
függvények léptek. Az alkalmazottak (Employee) listáját így írathatjuk ki: 


void print list(const listcEmployeet:€£ 5) 


for distkEmployee"5::const iterator p — s.beginO; p!-s.endO; 43p) // lásd §2.7.2 
Cp)-cprintO; 
j 


De akár így is: 
void print list(const listcEmployeet:d£ 5) 


for. each(s.beginO,s.endO,mem fun(rk Employee::prin2) ); // lásd §3.8.5 
J 


Minden Employee a típusának megfelelően íródik ki. A 


int mainŐ 


( 
Employee e("Broun", 12349; 
Manager mC Smith", 1234, 29; 
listsEmployee:: empl; 
empl.push front(ke); // §2.5.4 
empl.push front(km); 
brint listlrempD; 

J 


például az alábbi kimenetet eredményezi: 


Smith 1234 
szint 2 
Brown 1234 


Ez akkor is működik, ha a print listO függvényt azelőtt írtuk meg és fordítottuk le, mielőtt 
a Manager osztályt egyáltalán kitaláltuk volna! Ez az osztályoknak egy kulcsfontosságú tu- 
lajdonsága. Ha helyesen alkalmazzuk, az objektumorientált tervezés sarokköve lesz és 
a programok fejlesztésénél bizonyos fokú stabilitást ad. 
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Azt, hogy az Employee függvényei attól függetlenül , helyesen" viselkednek, hogy pontosan 
milyen fajta Employee-re hívtuk meg azokat, többalakúságnak (polimorfizmus, 
polymorphism) nevezzük. A virtuális függvényekkel bíró típus neve többalakúű típus 
(polimorfikus típus). A Cst nyelvben a többalakú viselkedést virtuális függvények haszná- 
latával vagy az objektumoknak mutatókon vagy referenciákon át való kezelésével érhetjük 
el. Ha közvetlenül kezelünk egy objektumot és nem mutató vagy referencia segítségével, 
a fordítóprogram felismeri annak pontos típusát, így a futási idejű többalakúságra nincs 
szükség. 


Világos, hogy a többalakúság támogatása érdekében a fordítóprogramnak minden Employee 
típusú objektumban valamilyen, a típusra vonatkozó információt (típusinformációD kell 
nyilvántartania, melynek segítségével képes a megfelelő print függvényt meghívni. Ehhez 
rendszerint egyetlen mutatónyi hely is elég, és erre is csak azon osztályokban van szükség, 
amelyeknek van virtuális függvényük; tehát nem minden osztályban és még csak nem is 
minden származtatott osztályban. A típusmezős megoldás választása esetén ehhez képest je- 


lentős mennyiségű tárterületet kellett volna a típusmező számára biztosítanunk. 


Ha egy függvényt (miként a Manager::brintO-et is) a :: hatókör-feloldó operátor segítségé- 
vel hívunk meg, akkor ezáltal kikapcsoljuk a virtualitást. Máskülönben a Manager::printO 
végtelen rekurziót idézne elő. A minősített név használatának van még egy előnye: ha egy 
virtuális függvény inline (ami elő szokott fordulni), akkor a fordítóprogram a :: minősítővel 
jelzett hívásokat képes helyben kifejteni. Ennek segítségével a programozó hatékonyan ké- 
pes azokat az egyedi eseteket kezelni, amikor mondjuk egy virtuális függvény ugyanarra az 
objektumra egy másik függvényt is meghív. A Manager::printO függvény ennek példája. 
Minthogy a Manager::brintÖ meghívásakor meghatározzuk az objektum típusát, az 
Employee::printO ezt követő meghívásakor a típusról már nem kell újra dönteni. 


Érdemes megemlíteni, hogy a virtuális függvényhívás hagyományos és nyilvánvaló megva- 
lósítása az egyszerű közvetett függvényhívás (indirekció) (42.5.5), így a hatékonyság elvesz- 
tésétől való félelem ne riasszon vissza senkit a virtuális függvények használatától ott, ahol 
egy közönséges függvényhívás elfogadhatóan hatékony. 
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12.3. Absztrakt osztályok 


Sok osztály hasonlít az Employee osztályra annyiban, hogy önmagában és származtatott 
osztályok bázisosztályaként is hasznos. Az ilyen osztályok számára elegendőek az előző 
pontban bemutatott módszerek. De nem minden osztály ilyen. Bizonyos osztályok, példá- 
ul a Shape (Alakzat), olyan elvont fogalmakat jelenítenek meg, amelyekhez nem létezhet- 
nek objektumok. A Shape-nek csak mint bázisosztálynak van értelme. Ez abból is látható, 


hogy nem tudunk hozzá virtuális függvényeket értelmesen definiálni: 


class Shape ( 

bublic: 
virtual void rotate(int) ( errorCShape::rotate"); ) // nem "elegáns" 
virtual void drauO f errorCShape::draw"); ) 
Tf 

h 


Egy ilyen meghatározatlan alakzatot meg tudunk ugyan adni (a nyelv megengedi), de nem 
sok értelme van: 


Shapes;  // butaság: "alak nélküli alakzat" 
A dolog azért értelmetlen, mert az s minden művelete hibát fog eredményezni. 
Jobb megoldás, ha a Shape osztály virtuális függvényeit tisztán virtuális (pure virtual) függ- 


vényként deklaráljuk. A virtuális függvények az -0 , kezdeti értékadástól" lesznek tisztán 
virtuálisak: 


class Shape f // absztrakt osztály 

public: 
virtual void rotate(int) - O; // tisztán virtuális függvény 
virtual void drawO —- 0; // tisztán virtuális függvény 
virtual bool is closedŐ — 0; // tisztán virtuális függvény 
Ve 

j; 


Ha egy osztály legalább egy tisztán virtuális függvénnyel rendelkezik, akkor absztrakt osz- 
tálynak (elvont osztály, abstract class) hívjuk, ilyen osztályba tartozó objektumot pedig nem 
hozhatunk létre: 


Shapes;  // hiba: s az absztrakt Shape osztály változója lenne 
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Az absztrakt osztályokat csak felületként (interface), illetve más osztályok bázisosztályaként 
használhatjuk: 


class Point €(/E ... "/ 2; 


class Circle : public Shape ( 


bublic: 
void rotate(int) ( ) // a Shape::rotate felülírása 
void drawO; // a Shape::draw felülírása 
bool is closedO f return true; ? // a Shape::is closed felülírása 


Circle(Point p, int r); 
brivate: 

Point center; 

int radius; 


Ha egy tisztán virtuális függvényt a származtatott osztályban nem definiálunk, akkor az tisz- 
tán virtuális függvény marad, sőt, a származtatott osztály is absztrakt osztály lesz. Ez a meg- 
valósítás lépcsőzetes felépítését teszi lehetővé: 


class Polygon : public Shape f // absztrakt osztály 
bublic: 
bool is closedO f return true; ) // a Shape::is closed felülírása 


// ... a draw és a rotate nincs felülírva ... 


J; 


Polygon b; // hiba: a Polygon osztálynak nem lehet objektuma 


class Irregular. polygon : public Polygon f 
listcPoint: Ip; 


bublic: 
void drawO; // a Shape::draw felülírása 
void rotate(int9; // a Shape::rotate felülírása 
V/ARST 
3; 
Irregular polygon poly(some points); // jó (megfelelő konstrukort feltételezve) 


Az absztrakt osztályok fontos képessége, hogy segítségükkel a megvalósítás egyéb részei- 
nek elérhetővé tétele nélkül biztosíthatunk felületet. Egy operációs rendszer például egy 
absztrakt osztály mögé rejtheti eszközmeghajtóinak tulajdonságait: 


class Character. device ( 

bublic: 
virtual int open(int opt) — O; 
virtual int close(int opt) — O; 
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virtual int read(char?" p, int n) — 0; 

virtual int write(const char" p, int n) - O; 

virtual int ioctl(int ...) — O; 

virtual -Character. deviceO f ) // virtuális destruktor 
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Az egyes eszközmeghajtókat a Character device-ból származtatott osztályként 
definiálhatjuk, és sokféle eszközmeghajtót kezelhetünk ezen felületen keresztül. A virtuális 
destruktorok fontosságát a §12.4.2 pont magyarázza el. 


Az absztrakt osztályok bevezetésével immár minden eszköz a kezünkben van arra, hogy 
moduláris módon, építőkövekként osztályokat használva egy teljes programot írjunk. 


12.4. Osztályhierarchiák tervezése 


Vegyük a következő egyszerű tervezési problémát: hogyan lehet egy program számára lehe- 
tővé tenni egy egész érték bekérését a felhasználói felületről? Zavarbaejtően sokféle módon. 
Ahhoz, hogy elszigeteljük programunkat ettől a sokféleségtől és felderíthessük a különböző 
tervezési módokat, kezdjük a munkát ezen egyszerű adatbeviteli művelet modelljének felál- 


lításával. A tényleges felhasználói felület elkészítésének részleteit későbbre halasztjuk. 


Az alapötlet az, hogy lesz egy Ival box (értékmező) osztályunk, amely tudja, hogy milyen 
értékeket fogadhat el. A program elkérheti egy /val box objektum értékét és felszólíthatja 
arra is, hogy kérje be ezt az értéket a felhasználótól, ha még nem áll rendelkezésre. Azt is 
megkérdezheti, hogy az érték megváltozott-e a legutóbbi kérés óta. 


Minthogy ez az alapötlet sokféleképpen megvalósítható, abból kell kiindulnunk, hogy sok- 
féle különböző /val box lesz: csúszkák, szöveges adatbeviteli mezők, ahová a felhasználó 
beírhatja az értéket, számtárcsák, hanggal vezérelhető eszközök. 


Azt az általános megközelítést alkalmazzuk, hogy egy virtuális felhasználói felületet" bocsá- 
tunk az alkalmazás rendelkezésére, amely a létező felhasználói felületek szolgáltatásainak 
lesz. 
Természetesen vannak más módok is arra, hogy egy alkalmazást elválasszunk a felhaszná- 


Ap 


egy részét biztosítja. E felület számos rendszeren elkészíthető, így kódja , hordozható 


lói felülettől. Azért választottam ezt, mert általános, mert a kapcsán egy sor eljárást és terve- 
zési szempontot lehet bemutatni, mert ezeket a módszereket alkalmazzák a valódi felhasz- 
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nálói felületeteket kezelő rendszerekben, és végül — a leglényegesebb ok -, mert ezek 
a módszerek a felhasználói felületetek szűk tartományánál jóval szélesebb körben is alkal- 
mazhatók. 


12.4.1. Hagyományos osztályhierarchia 


Első megoldásunk egy hagyományos osztályhierarchia; ilyennel a Simula, Smalltalk és ré- 
gebbi C----programokban találkozhatunk. 


Az Ival box osztály az összes Ival box által használatos felületet írja le és egy olyan alapér- 
telmezett megvalósítást ad, melyet az egyes /val box-ok sajátjaikkal felülbírálhatnak. Ezen- 
kívül megadjuk az alapmegoldáshoz szükséges adatokat is: 


class Ival box f 
brotected: 
int val; 
int low, high, 
bool changed; 
bublic: 
Ival boxcint II, int hh) ( changed - false; val - low — Il; high - hh; ) 


virtual int get valueO f changed - false; return val; ) 

virtual void set value(int i) f changed - true; val — i; ) // felhasználók számára 
virtual void reset value(int i) f changed - false; val — i; ) // alkalmazások számára 
virtual void promptO0 f ) 

virtual bool was changedO const f return changed; ) 


A függvények alapértelmezett változatai meglehetősen vázlatosak, ,pongyolák"; céljuk leg- 
inkább az, hogy illusztrálják a megközelítést. (Egy , valódi" osztály például értékellenőrzést 
is végezne.) 


Az , ival osztályokat" egy programozó így használhatná fel: 


void interact(Ival box? pb) 
( 
bb--promptO; // jelzés a felhasználónak 
VEB 
int i - pb-2get valuecO; 
if bb-2was changedO) f 
// új érték; valamit csinálunk vele 


j 


12. Származtatott osztályok 415 


else ( 
// a régi érték jó volt; ezt is felhasználjuk valahogy 
j 
7 
j 
void some fct0 
f 
Ival box? p1 - new Ival slider(0,5);  // az Ival slider az Ival box osztályból származik 
interact(p U; 
Ival box? p2 - new Ival diaKk1, 129; 
interact(p2; 
J 


A programkód legnagyobb része az interactÓ függvény stílusában íródna, és egyszerű 
Ival box-okat, illetve azokra hivatkozó mutatókat használna. Így a programnak nem kelle- 
ne tudnia az esetleg nagy számú különböző /val box-változatokról, csak annak a viszony- 
lag kis számú függvénynek kellene ismernie azokat, amelyek ilyen objektumokat létrehoz- 
nak. Ez a felhasználókat elszigeteli a származtatott osztályok esetleges módosításaitól. 
A kód legnagyobb részének még arról sem kell tudnia, hogy egyáltalán különböző 
Ival box-ok léteznek. 

Hogy egyszetűsítsem a tárgyalást, eltekintek attól a kérdéstől, hogyan vár a program beme- 
netre. Lehetséges megoldás, hogy a program a get valueO függvényben ténylegesen vár 
a felhasználói bemenetre, megoldható úgy is, hogy az Ival box-ot egy eseményhez kap- 
csoljuk és egy visszahívás Ccallback) segítségével válaszolunk, esetleg a programmal külön 
végrehajtási szálat indíttatunk el az Ival box számára, majd a szál állapotát kérdezzük le. 
Az ilyen döntések alapvető fontosságúak a felhasználói felületet kezelő rendszerek terve- 
zésekor, de ha itt a valóságot akár csak megközelítő részletességgel tárgyalnánk ezeket, el- 
vonnánk a figyelmet a programozási eljárások és nyelvi eszközök tárgyalásától. Az itt be- 
mutatott tervezési módszerek és az azokat támogató nyelvi eszközök nem kötődnek adott 
felhasználói felülethez; jóval szélesebb körben is alkalmazhatók. 


A különböző /val box-okat az Ival box-ból származtatott osztályokként határozhatjuk meg: 


class Ival slider : public Ival box ( 

// a csúszka kinézetét, viselkedését meghatározó grafikai elemek 
public: 

Ival sliderGint, int); 


int get valueO; 
void promptO; 
j; 


Az Ival box adattagjait védettként (protected) vezettük be, hogy a származtatott osztályok- 
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ból elérhetőek legyenek. Így aztán az Ival slider::get valueO függvény elhelyezheti az ér- 
téket az Ival box::val adattagban. A védett tagok elérhetők az osztály és a származtatott osz- 
tályok függvényei számára is, de az általános felhasználó számára nem (415.3). 


Az Ival box-ból az Ival slider mellett más változatokat is származtathatunk. Ezek között ott 
lehet az JIval dial, amelynél egy gomb forgatásával adhatunk meg egy értéket, 
a Flashing ival slider, amely felvillan, ha a bpromptO függvénnyel erre kérjük, és 
a Pobup ival slider, amely a promptO hatására valamilyen feltűnő helyen jelenik meg, 
a felhasználótól szinte kikövetelve egy érték megadását. 


De vajon honnan vegyük a grafikus elemeket? A legtöbb felhasználói felületet kezelő rend- 
szer biztosít egy osztályt, amely leírja a képernyőn levő objektumok alapvető tulajdonsága- 
it. Ha például a ,Big Bucks Inc." ( Sok Pénz Rt.") rendszerét használjuk, akkor az 
Ival slider, az Ival dial stb. osztáyok mindegyike egy-egy fajta BBwindow (Big Bucks 
window) kell, hogy legyen. Ezt a legegyszerűbben úgy érhetjük el, ha Ival box-unkat úgy 
írjuk át, hogy a BBwindow-ból származtatott osztály legyen. Így aztán az összes osztályunk 
a BBwindow-ból származtatott lesz, tehát elhelyezhető lesz a képernyőn, megjelenése iga- 
zodik majd a rendszer többi grafikus elemének megjelenéséhez, átméretezhető, áthelyez- 
hető lesz stb., a BBwindow rendszer szabályainak megfelelően. Osztályhierarchiánk tehát 
így fog kinézni: 


class Ival box : public BBwindow f /§ ... "/]; — / újraírva a BBwindow használatára 
class Ival slider : public Ival box £/? ... "/); 

class Ival dial : public Ival box £/? ... "/); 

class Flashing ival slider : public Ival slider € /? ... "/ ); 

class Popup ival slider : public Ival slider€/? ... "/ 3; 


Ábrával: 


BBwindow 
Ival box 
Ival slider Ival dial 


sé 


Popup ival slider Flashing ival slider 
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12.4.1.1. Bírálat 


Ez így sok tekintetben jól fog működni és az ilyesfajta osztályfelépítés számos problémára 
jó megoldás. Ám van néhány hátulütője, melyek miatt más tervezési lehetőségek után fo- 
gunk nézni. 


A BBwindow osztályt utólag tettük az Ival box bázisosztályává, ami nem egészen helyes. 
A BBwindow osztály nem alapvető része az Ival box-ra épített rendszernek, megléte csu- 
pán részletkérdés. Az, hogy az Ival box a BBwindow osztály leszármazottja, ezt a részlet- 
kérdést elsőrendű tervezési döntéssé emeli. Ez abban az esetben helyes, ha cégünk kulcs- 
fontosságú üzleti döntése, hogy a , Big Bucks Inc." által biztosított környezetet használjuk. 
De mi történik, ha Ival box-unkat olyan rendszerekre is át szeretnénk ültetni, melyek az 
, Imperial Bananas", a , Liberated Software" vagy a , Compiler Whizzles"-től származnak? Ek- 
kor programunkból négy változatot kellene készítenünk: 


class Ival box : public BBwindow f /? ... "/ ); // BB változat 
class Ival box : public CWwindow £ /§ ... "/ ); // CW változat 
class Ival box : public IBwindow f /? ... "/ ); // IB változat 
class Ival box : public ISwindow f /£ ... "/ ?; // IS változat 


Ha ennyi változatunk van, módosításuk, változatkövetésük rémálommá válhat. 


Egy másik probléma, hogy az Ival box-ban deklarált adatok minden származtatott osztály 
rendelkezésére állnak. Ezek az adatok megint csak egy , apró" részletet jelentenek, mégis 
bekerültek az /val box felületbe. Ez gyakorlati szempontból azt is jelenti, hogy nem bizto- 
sított, hogy mindig a megfelelő adatot kapjuk. Az Ival slider esetében például nem szüksé- 
ges az adat külön tárolása, minthogy ez a csúszka állásából meghatározható, valahányszor 
végrehajtják a get valueO-t. Általában is problematikus két rokon, de eltérő adathalmaz tá- 
rolása. Előbb-utóbb valaki eléri, hogy ne legyenek többé összhangban. A tapasztalat is azt 
mutatja, hogy kezdő programozók szükségtelen és nehezebb módosíthatóságot eredmé- 
nyező módon szeretnek a védett (protected) adattagokkal ügyeskedni. Jobb, ha az adatta- 
gok privátok, mert így a származtatott osztályok írói nem zavarhatják össze azokat. Még 
jobb, ha az adatok a származtatott osztályokban vannak, mert akkor pontosan meg tudnak 
felelni a követelményeknek és nem keseríthetik meg az egymással nem rokon származta- 
tott osztályok életét. A védett felület szinte mindig csak függvényeket, típusokat és konstan- 
sokat tartalmazzon. 


Ha az Ival box a BBwindow-ból származik, ez azzal az előnnyel jár, hogy az Ival box fel- 
használói a BBwindow minden szolgáltatását igénybe vehetik, ami sajnos azt is jelenti, hogy 
a BBwindow osztály változásakor az /val box felhasználóinak újra kell fordítaniuk, esetleg 
újra kell írniuk a kódjukat. A legtöbb C---változat úgy működik, hogy ha egy bázisosztály 
mérete megváltozik, akkor az összes származtatott osztályt újra kell fordítani. 
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Végül lehetséges, hogy programunknak olyan vegyes környezetben kell futnia, ahol külön- 
böző felhasználói felületek ablakai léteznek egyidejűleg. Vagy azért, mert valahogy ezek 
egy képernyőn tudnak osztozni, vagy mert programunknak különböző rendszerek felhasz- 
nálóival kell kapcsolatot tartania. Ehhez pedig nem elég rugalmas megoldás, ha a felhasz- 
nálói felületet az egyetlen /val box felületünk bázisosztályaként , bedrótozzuk". 


12.4.2. Absztrakt osztályok 


Nos, kezdjük újra a tervezést, hogy megoldjuk a hagyományos felépítés bírálatában felve- 
tett problémákat: 


1. A felhasználói felület valóban olyan részletkérdés legyen, amelyről nem kell 
tudomást venniük azon felhasználóknak, akiket nem érdekel. 

2. Az Ival box osztály ne tartalmazzon adatokat. 

3. Ha megváltozik a felhasználói felületet kezelő rendszer, ne legyen szükséges 
az Ival box családot felhasználó kód újrafordítása. 

4. Különböző felhasználói felületekhez tartozó /val box-ok tudjanak egyszerre 
létezni a programban. 


Többféle megoldás kínálkozik erre; most egy olyat mutatok be, amely tisztán megvalósít- 
ható a Ct-4 nyelvvel. 


Először is, az Ival box osztályt puszta felületként (pure interface) határozzuk meg: 


class Ival box f 

bublic: 
virtual int get value - 0; 
virtual void set value(int i) — O; 
virtual void reset value(int i) — O; 
virtual void promptO —- 0; 
virtual bool was changedO const - 0; 
virtual -Ival boxO 1 ; 


Jo 


Ez sokkal világosabb, mint az /val box osztály eredeti deklarációja volt. Elhagytuk az adat- 
tagokat és a tagfüggvények egyszerűsített kifejtését is. Elmaradt a konstruktor is, mivel 
nincs kezdőértékre váró adat. Ehelyett egy virtuális destruktorunk van, amely biztosítja az 


öröklő osztályok adatainak helyes , eltakarítását". 
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Az Ival slider definíciója így alakulhat: 


class Ival slider : public Ival box, protected BBwindow ( 
public: 

Ival sliderGint, int); 

-Ival sliderO; 


int get valueO; 

void set value(int i); 

4//0csA 
protected: 

// a BBwindow virtuális függvényeit felülírő függvények 

// pl. BBwindow::drawO, BBwindow::mouse1hitO 
brivate: 

// a csúszka adatai 


Vai 


Mivel az J/val slider osztály az absztrakt Ival box osztályból származik, meg kell valósítania 
annak tisztán virtuális (pure virtual) függvényeit. A BBwindow osztályból is származik, ezért 
onnan valók az eszközei, melyekkel ezt megteheti. Az Ival box adja a származtatott osztály 
felületét, ezért nyilvános (public) módon származik onnan. Mivel a BBwindow osztályból 
való származása mindössze segítséget nyújt a megvalósításhoz, onnan védett (protected) 
módon származik (§15.3.2)9. Ebből következik, hogy az /val slider-t felhasználó programozó 
nem használhatja közvetlenül a BBwindow által nyújtott eszközöket. Az /val slider felülete 
az Ival box-tól örökölt részből áll, illetve abból, amit maga az Ival slider kifejezetten 
deklarál. Azért használunk védett származtatást a szigorúbb megkötést jelentő (és általában 
biztonságosabb) privát helyett, hogy az J/val slider-ből származtatott osztályok számára 
a BBwindow-t elérhetővé tegyük. 


A több osztályból való közvetlen öröklődést általában többszörös öröklődésnek (multiple 
inheritance) hívják (415.29. Vegyük észre, hogy J/val slider-nek mind az Ival box, mind 
a BBwindow függvényei közül felül kell írnia néhányat, ezért közvetve vagy közvetlenül 
mindkét osztályból származnia kell. Mint a §12.4.1.1 pontban láttuk, lehetséges ugyan az 
Ival slider közvetett származtatása a BBwindow-ból Cazáltal, hogy az Ival box 
a BBwindow-ból származik), de ez nemkívánatos mellékhatásokkal jár. Hasonlóan, az az 
út, hogy a BBwindow , megvalósítási osztály" tagja legyen az Ival box-nak, nem járható, 
mert egy osztály nem írhatja felül tagjainak virtuális függvényeit (424.3.4). Az ablaknak az 
Ival box osztály egy BBwindow?" típusú tagjaként való ábrázolása teljesen eltérő szerkezet- 
hez vezet, melynek megvannak a maga előnyei és hátrányai (412.7I14], $25.79. 


Érdekes módon az J/val slider ilyen módon való deklarálása esetén ugyanolyan kódot írha- 
tunk, mint azelőtt. Csak azért változtattunk, hogy a szerkezet logikusabb módon tükrözze 
a megvalósítást. 
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Számos osztálynak szüksége van valamilyen , rendrakásra", mielőtt egy objektuma meg- 
semmisül. Mivel az absztrakt I/val box osztály nem tudhatja, hogy egy származtatott osztály- 
nak nincs-e szüksége erre, fel kell tételeznie, hogy igenis szükség van rá. A rendrakást úgy 
biztosítjuk, hogy a bázisosztályban definiáljuk az Ival box::-Ival boxO virtuális destruktort 
és a származtatott osztályokban megfelelő módon felülírjuk azt: 


void fdval box? p) 
( 

/AgB 

delete p; 


j 


A delete operátor megsemmisíti az objektumot, amelyre b mutat. Nem tudhatjuk, hogy pon- 
tosan milyen osztályú objektumról van szó, de mivel az Ival box-nak virtuális destruktora 
van, a megfelelő destruktor fog meghívódni, (ha az adott osztálynak van ilyen). 


Az Ival box hierarchiát most így írhatjuk le: 


class Ival box €/? ... "/ 3; 

class Ival slider : public Ival box, protected BBwindow f / ... "/ ); 
class Ival dial : public Ival box, protected BBwindow f / ... "/ ); 
class Flashing ival slider : public Ival slider € /? ... "/ ); 

class Popup ival slider : public Ival slider€/? ... "/ 3; 


Egyszerű rövidítésekkel pedig így ábrázolhatjuk: 


BBwindow Ival box BBwindow 
1val slider fúáL dig 
Popup slider Flashing slider 


A szaggatott nyilak a védett (protected) módú öröklődést jelölik. Az általános felhasználók 
számára ezek csak részletkérdések. 
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12.4.3. Egyéb megvalósítások 


Ez a szerkezet tisztább és könnyebben módosítható, mint a hagyományos, de nem kevés- 
bé hatékony. A változatkövetési problémát azonban nem oldja meg: 


class Ival box £/5..."79); // közös 
class Ival slider : public Ival box, protected BBwindow f / ... "/); // BB 
class Ival slider : public Ival box, protected CWwindow ( /? ... "/ ); / Cw 
Ms 


Ráadásul a BBwindow-hoz és a CWwindow-hoz írt Ival slider-ek nem létezhetnek együtt, 
még akkor sem, ha egyébként maguk a BBwindow és CWwindow felhasználói felületek 
igen. 


A nyilvánvaló megoldás az, hogy különböző nevű Z/val slider osztályokat hozunk létre: 


class Ival box £/5 ... 7); 

class BB ival slider : public Ival box, protected BBwindow f / ... "/ ); 
class CW ival slider : public Ival box, protected CWwindow ( /? ... "/ 3; 
Ze 


Ábrával: 


BBwindow Ival box CWwindow 


BB. íval slider CW i val slider 


Hogy programunk /val box osztályait jobban elszigeteljük a megvalósítás egyéb részletei- 
től, származtathatunk egy absztrakt /val slider osztályt az Ival box-ból, majd ebből örököl- 
tethetjük az egyes rendszerfüggő J/val slider-eket: 


class Ival box £/5 ... "/); 

class Ival slider : public Ival box (f /? ... "/ 2; 

class BB ival slider : public Ival slider, protected BBwindow (f / ... "/ ); 
class CW ival slider : public Ival slider, protected CWwindow f / ... "/ ); 
MI ... 
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Ábrával: 
Ival box 
BBwindow Ival slider CWwindow 
m sz gy LV 
BB ival slider CW ival slider 


Általában még ennél is jobban járunk, ha a hierarchiában egyedibb osztályokat használunk. 
Ha például a ,Big Bucks Inc." rendszerében van egy csúszka (slider) osztály, akkor a mi 
Ival slider-ünket közvetlenül a BBslider-ből származtathatjuk: 


class BB ival slider : public Ival slider, protected BBslider f / ... "/ ); 
class CW ival slider : public Ival slider, protected CWslider € /? ... "/ ); 


Ábrával: 


BBwindow Ival box CWwindow 


BBs$lider Ival slider CWslider 


BB i val slider CW ival slider 


Ez a javítás jelentős lehet abban a (sűrűn előforduló) esetben, ha a mi fogalmaink nem es- 
nek távol a megvalósítás céljából felhasznált rendszer fogalmaitól. Ekkor a programozás tu- 
lajdonképpen a rokon fogalmak közötti leképezésre egyszerűsödik, és a BBwindow-hoz 
hasonló általános bázisosztályokból való öröklődés ritkán fordul elő. A teljes hierarchia 
egyrészt az eredeti, alkalmazásközpontú rendszer származtatott osztályokként megvalósí- 
tott felületeinek viszonyrendszeréből fog állni: 


class Ival box f€/? ... "/ 3); 

class Ival slider : public Ival box f£/? ... "/); 

class Ival dial : public Ival box £/? ... "/); 

class Flashing ival slider : public Ival slider € /? ... "/ ); 
class Popup ival slider : public Ival slider€/? ... "/ 3; 
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Illetve a hierarchiát — szintén az öröklődés segítségével — többféle grafikus felhasználói felü- 
letre leképező származtatott osztályokból: 


class BB ival slider : public Ival slider, protected BBslider £ / ... "/ ); 
class BB flashing ival slider : public Flashing ival slider, 
protected BBwindow with bells and whistles (/? ..."/); 
class BB popup ival slider : public Popup ival slider, protected BBsSlider £ / ... "/ ?; 
class CW ival slider : public Ival slider, protected CWslider f / ... "/ ); 
v/v 


A kapott felépítményt egyszerű rövidítések segítségével így ábrázolhatjuk: 
Ival box 


Ival slider Ival dial 








ipopup 
A 








BBslider BBslider CWsl CWsI CWsI 
A A 4 xy A 
BBislider BBipop — CWipop CWifI BBifl cCWislider 


Az eredeti Ival box hierarchia változatlan marad, csak a konkrét megvalósítást végző osz- 
tályok veszik körül. 


12.4.3.1. Bírálat 


Az absztrakt osztályokat használó osztályszerkezet rugalmas és majdnem ugyanolyan egy- 
szerűen kezelhető, mint a konkrét felhasználói felületet bázisosztályként szerepeltető. 
Az utóbbiban a fa gyökere a megfelelő ablakosztály, az előbbiben viszont változatlanul az 
alkalmazás osztályhierarchiája marad a tényleges megvalósítást végző osztályok alapja. 
A program szempontjából ezek a szerkezetek egyenértékűek abban az értelemben, hogy 
majdnem az egész kód változtatás nélkül és ugyanúgy működik mindkét esetben, és mind- 
kettőnél az alkalmazott felhasználói felülettől függő elemekre való tekintet nélkül vizsgál- 
hatjuk az Ival box család osztályait. A §12.4.1-beli interactO függvényt például nem kell új- 
raírnunk, ha az egyik szerkezetről a másikra váltunk. 
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Mindkét esetben újra kell írnunk az egyes Ival box osztályokat, ha a felhasználói felület 
nyilvános felülete megváltozik, de az absztrakt osztályokat használó szerkezet esetében 
szinte az egész kód védett a megvalósítás változásától és egy ilyen változás után nem kell 
újrafordítani. Ez különösen akkor fontos, ha a megvalósítást végző elemek készítője egy új, 
, majdnem kompatibilis" változatot bocsát ki. Ráadásul az absztrakt osztályos megoldást vá- 
lasztók a klasszikus hierarchia híveinél kevésbé vannak kitéve az egyedi, máshol nem hasz- 
nálható megvalósítás csapdájába való bezáródás veszélyének. Az elvont Ival box osztá- 
lyokra épített programot választva nem használhatjuk , véletlenül" a megvalósító osztályok 
nyújtotta lehetőségeket, mert csak az /val box hierarchiában kifejezetten megadott lehető- 
ségek érhetők el, semmi sem öröklődik automatikusan egy rendszerfüggő bázisosztálytól. 


12.4.4. Az objektumok létrehozásának adott helyre korlátozása 


A program legnagyobb része megírható az /val box felület felhasználásával. Ha a származ- 
tatott felületek továbbfejlődnek és több szolgáltatást nyújtanak, mint a sima /val box, akkor 
nagyrészt használhatjuk az Ival box, Ival slider stb. felületeket. Az objektumokat azonban 
az adott rendszerre jellemző nevek (például CW ival dialés BB flashing ival slider) fel- 
használásával kell létrehozni. Jó lenne, ha az ilyen rendszerfüggő nevek minél kevesebb 
helyen fordulnának elő, mivel az objektumok létrehozása nehezen köthető helyhez, hacsak 
nem szisztematikusan járunk el. 


Szokás szerint az indirekció (közvetett hivatkozás) bevezetése a megoldás. Ezt többfélekép- 
pen is megtehetjük. Egyszerű megoldás lehet például egy olyan osztály bevezetése, amely 


az objektumokat létrehozó műveletekért felelős: 


class Ival maker f 


bublic: 
virtual Ival dial" dial(int, int) -O; // tárcsa (diaD készítése 
virtual Popup ival slider" bopup sliderGint, int) -O; // előugró csúszka (popup slider) 
// készítése 
Mézó 


Az Ival maker osztály az Ival box hierarchia minden olyan felülete számára rendelkezik az 
adott típusú objektumot létrehozó függvénnyel, mely felületről a felhasználók tudhatnak. 
Az ilyen osztályokat gyárnak (factory) hívják, függvényeiket pedig — némiképp félreveze- 
tő módon — virtuális konstruktoroknak (§15.6.2). 
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Az egyes különböző felhasználói felületeket kezelő rendszereket most az Ival maker osz- 
tályból származtatott osztályokként ábrázoljuk: 


class BB maker : public Ival maker ( // BB-változatok készítése 
bublic: 

Ival dial" dialGnt, int); 

Popup ival slider" popup sliderCGint, int); 


17 és 
Fé. 
class ILS maker : public Ival maker f // LS-változatok készítése 
bublic: 
Ival dial" dialGnt, int); 
Popup ival slider" popup sliderGint, int); 
V/ARPE 
h 


Minden függvény a kívánt felületű és megvalósítási típusú objektumot hozza létre: 


Ival dial" BB maker::dial(int a, int b) 


f 
return new BB ival dialca,b); 
J 
Ival dial" LS maker::dial(int a, int b) 
f 
return new LS ival dialca, b); 
j 


Ha adott egy mutató egy Ival maker objektumra, akkor a programozó ennek segítségével 
úgy hozhat létre objektumokat, hogy nem kell tudnia, pontosan milyen rendszerű felhasz- 
nálói felület van használatban: 


void user(dval maker?" bim) 


( 
Ival box: pb - bim-2diak(O,99); " / megfelelő tárcsa létrehozása 
Ve 
j 
BB maker BB impl; // BB-felhasználóknak 
IS maker LS impl; // IS-felhasználóknak 
void driverŐ 
( 
user(k BB impD; // BB használata 
user(kILS impD; // ES használata 
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12.5. Osztályhierarchiák és absztrakt osztályok 


Az absztrakt osztályok felületek (interface). Az osztályhierarchia annak eszköze, hogy foko- 
zatosan építsünk fel osztályokat. Természetesen minden osztály ad egy felületet a progra- 
mozó számára, némely absztrakt osztály pedig jelentős szolgáltatásokat kínál, amelyekre 
építhetünk, de , felület" és ,építőkő" szerepük alapvetően az absztrakt osztályoknak és az 
osztályhierarchiáknak van. 


Klasszikus hierarchiának azt a felépítést nevezzük, amelynek egyes osztályai hasznos szol- 
gáltatásokat kínálnak a felhasználóknak, illetve egyben a fejlettebb vagy egyedi feladatot 
végző osztályok számára építőkőül szolgálnak. Az ilyen felépítés ideálisan támogatja a lé- 
pésenkénti finomítással való fejlesztést, illetve az új osztályok létrehozását, amennyiben 
ezek megfelelően illeszkednek a hierarchiába. 


A klasszikus felépítés a tényleges megvalósítást sokszor összekapcsolja a felhasználóknak 
nyújtott felülettel. Ez ügyben az absztrakt osztályok segíthetnek. Az absztrakt osztályok se- 
gítségével felépített rendszer tisztább és hatékonyabb módot ad a fogalmak kifejezésére, 
anélkül hogy a megvalósítás részleteivel keveredne vagy jelentősen növelné a program fu- 
tási idejét. A virtuális függvények meghívása egyszerű és független attól, hogy miféle elvo- 
natkoztatási réteg határát lépi át. Egy absztrakt osztály virtuális függvényét meghívni sem- 
mivel sem kerül többe, mint bármely más virtuális függvényt. 


A fentiekből adódó végkövetkeztetés az, hogy egy rendszert a felhasználók felé mindig 
absztrakt osztályok hierarchiájaként mutassunk, de klasszikus hierarchiaként építsünk fel. 


12.6. Tanácsok 


[1] Kerüljük a típusmezők alkalmazását. §12.2.5. 

[2] Az objektumok felszeletelődését (slicing) elkerülendő használjunk mutatókat és 
referenciákat. §12.2.3. 

[3] Használjunk absztrakt osztályokat, hogy a világos felületek elkészítésére össz- 
pontosíthassunk. §12.3. 

l4] Használjunk absztrakt osztályokat, hogy minél kisebb felületeket használhas- 
sunk. §12.4.2. 

[5] Használjunk absztrakt osztályokat, hogy a felületeket elválasszuk a megvalósítá- 
si részletektől. §12.4.2. 
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[6] Használjunk virtuális függvényeket, hogy később új megvalósítást készíthessünk 
a meglevő felhasználói kód befolyásolása nélkül. §412.4.1. 

[71 Használjunk absztrakt osztályokat, hogy minél kevesebbszer kelljen a felhaszná- 
lói kódot újrafordítani. §12.4.2. 

[8] Használjunk absztrakt osztályokat, hogy a program többféle rendszeren is mű- 
ködjön. §12.4.3. 

[9] Ha egy osztálynak van virtuális függvénye, akkor legyen virtuális destruktora is. 
§12.4.2. 

[10] Az absztrakt osztályoknak általában nincs szükségük konstruktorra. 12.4.2. 

[11] Az önálló fogalmakat külön ábrázoljuk. §12.4.1.1. 


12.7. Gyakorlatok 


1. G1) Ha adott a következő: 


class Base ( 
public: 
virtual void iamO f cout c£ "Bázisosztály"; ) 


35 


Származtassunk két osztályt a Base-ből, mindegyiknek legyen egy iamO függ- 
vénye, amely kiírja az osztály nevét. Hozzunk létre egy-egy ilyen osztályú ob- 
jektumot és hívjuk meg rájuk az iamO függvényt. Rendeljünk a származtatott 
osztályok objektumaira hivatkozó mutatókat Base" típusú mutatókhoz és hívjuk 
meg ezeken keresztül az iamO függvényt. 

2. C3.5) Készítsünk egy egyszerű grafikus rendszert a rendelkezésünk álló grafi- 
kus felhasználói felület felett. (Ha nincs ilyen vagy nincs tapasztalatunk ilyesmi- 
vel, akkor készíthetünk egy egyszerű, ASCII karakterekből felépített megvalósí- 
tást, ahol egy pont egy karakterpozíciónak felel meg, és az írás a megfelelő 
karakter, mondjuk a ?" megfelelő pozícióra való helyezését jelenti.) 

Ebben a feladatban és a továbbiakban a következő osztályokat használjuk: 
Window (Ablak), Point (Pont), Line (Vonal), Dot (Képernyőpont), Rectangle 
(Téglalap), Circle (Kör), Shape (Alakzat, Idom), Sguare (Négyzet) és Triangle 
(Háromszög). 

A Windou(n m) hozzon létre egy n-szer m méretű területet a képernyőn. 

A képernyő pontjait az (x,y) derékszögű (descartes-i) koordináták segítségével 
címezzük meg. A Window osztályba tartozó w aktuális helye — w.currentO — 
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kezdetben Point(O,0). A pozíciót a w.current(p) hívással állíthatjuk be, ahol p 
egy Point. A Point objektumokat egy koordináta-pár adja meg: Point(Xx, y); 

a Line objektumokat egy Point pár — Line(w.currentO,p2) —, a Shape osztály 

a Dot, a Line, a Rectangle, a Circle stb. közös felülete. Egy Point nem Shape is 
egyben. A Dot(pJ-ként létrehozott Dot egy Point b-t jelent a képernyőn. 

A Shape-ek nem láthatók, amíg a drawO függvényt meg nem hívjuk; például: 
w.drau(Circle(w.current(), 109). Minden Shabe-nek 9 érintkezési pontja van: e 
Ceast — kelet), w (west — nyugat), n (north — észak), s (south — dél), ne (északke- 
le), nw (északnyugat), se (délkelet), sw (délnyuga0) és c (center — középponD. 
A Line(x.cO,y.nwO) például egy vonalat húz az x közepétől az y bal felső sar- 
kához. Ha egy Shape-re alkalmaztuk a drawO függvényt, az aktuális pozíció 

a Shape se0-je lesz. Egy Rectangle-t a bal alsó és a jobb felső csúcsával adunk 
meg; Rectangle(w.currentO, Point( 10, 109). Egyszerű tesztként jelenítsünk meg 
egy gyermekrajzot, amely egy házat ábrázol tetővel, két ablakkal, és egy ajtóval. 


. 2) Egy Shape fontos részei szakaszokként jelennek meg a képernyőn. Adjunk 


meg olyan műveleteket, amelyek segítségével meg tudjuk változtatni ezen sza- 
kaszok kinézetét. Az s.thickness(n) a O, 1,2,3 értékek valamelyikére állítsa be 

a vonalszélességet, ahol a 2 az alapértelmezett érték és a O érték azt jelenti, 
hogy a vonal láthatatlan. A vonal lehessen tömör, szaggatott vagy pontokból 
álló is. Ezt a Shape::outlineO tüggvény állítsa be. 


. (2.5) Írjuk meg a Line::arrowheadO függvényt, amely egy vonal végére egy 


nyilat rajzol. Minthogy egy vonalnak két vége van és a nyíl a vonalhoz képest 
kétféle irányba mutathat, így az arrowheadO függvény paramétere vagy para- 
méterei ki kell, hogy tudják fejezni ezt a négyféle lehetőséget. 


. C3.5) Gondoskodjunk arról, hogy azon pontok és vonalszakaszok, amelyek 


kívül esnek egy Window-n, ne jelenjenek meg. Ezt a jelenséget gyakran hívják 
, levágásnak" (clipping). E célból — gyakorlatként — ne hagyatkozzunk a felhasz- 
nált grafikus felhasználói felületre. 


. (2.5) Egészítsük ki grafikai rendszerünket a 7ext típussal. A 7ext legyen egy 


téglalap alakú Shape, amely karaktereket tud megjeleníteni. Alapértelmezés sze- 
rint egy karakter a koordináta-tengelyen minden irányban egy egységnyi helyet 
foglaljon el. 


. 2) Határozzunk meg egy függvényt, amely megtalálja két Szape egymáshoz 


legközelebbi pontjait és összeköti azokat. 


. C3) Vezessük be grafikai rendszerünkbe a szín fogalmát. Háromféle dolog lehet 


színes: a háttér, egy zárt Shape belseje és egy Shape határa. 


9: 
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(2) Vegyük az alábbi osztályt: 


class Char. vec f 
int Sz; 
char element[1]; 

public: 
static Char. vec: new char. vec(int 5); 
charg operatorf [int i) ( return elementlij; ) 
Zan 

J; 


Definiáljuk a new char vecO-t, hogy egybefüggő memóriaterületet foglalhas- 

sunk le egy Char. vec objektum számára, így elemeit az element0 függvénnyel 
indexelhetjük. Milyen körülmények között okoz ez a trükk komoly problémá- 
kat? 


10. (2.5) Ha adottak a Shape osztályból származó Circle, Sguare és Triangle osztá- 


11. 


12. 


lyok, határozzuk meg az intersectŐ függvényt, amely két Shape" paramétert 
vesz és a megfelelő függvények meghívásával megállapítja, hogy a két Shape át- 
fedő-e, metszi-e egymást. Ehhez szükséges lesz az osztályok megfelelő (virtuá- 
lis) függvényekkel való bővítése. Ne írjuk meg az átfedés tényleges megállapítá- 
sára szolgáló kódot, csak arra ügyeljünk, hogy a megfelelő függvényeket hívjuk 
meg. Ezt az eljárást angolul általában , double dispatch" vagy , multi-method" 
néven emlegetik. 

(5) Tervezzünk és írjunk meg egy eseményvezérelt szimulációkat végző 
könyvtárat. Segítség: nézzük meg a ctask.h: fejállományt. Ez egy régi program, 
az olvasó jobbat tud írni. Legyen egy task nevű osztály. A task osztályú objektu- 
mok legyenek képesek állapotuk mentésére és visszaállítására (mondjuk 

a task::saveO és a task::restoreO függvényekkel), hogy kiegészítő eljárásként 
(co-routine) működhessenek. Az egyes elvégzendő feladatokat a task osztályból 
öröklő osztályok objektumaiként adhassuk meg. A task-ok által végrehajtandó 
programokat virtuális függvényekkel határozzuk meg. Egy új task számára le- 
gyen lehetséges paramétereket megadni konstruktora(dnak paramétereként. 
Legyen egy ütemező, amely megvalósítja a virtuális idő fogalmát. Legyen egy 
task:: delay(long) függvény, amely , fogyasztja" ezt a virtuális időt. Az, hogy ez 
az ütemező a task része vagy önálló osztály lesz-e, a fő tervezési döntések egyi- 
ke. A task-oknak kapcsolatot kell tartaniuk egymással. Erre a célra tervezzünk 
egy gueue osztályt. Egy task-nak legyen lehetősége több forrás felől érkező be- 
menetre várakozni. Kezeljük a futási idejű hibákat azonos módon. Hogyan le- 
hetne egy ilyen könyvtárat használó programban hibakeresést végezni? 

(2) Határozzuk meg egy kalandjáték számára a Warrior (harcos), Monster 
(szörny) és Object (tárgy; olyasmi, amit fel lehet kapni, el lehet dobni, használni 
lehet stb.) osztályok felületét. 
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13.C1.5) Miért van a §12.7[2]-ben Point és Dot osztály is? Milyen körülmények kö- 
zött lenne jó ötlet a Shape osztályokat a kulcsosztályok, például a Zine konkrét 


változataival bővíteni? 

14.(C3) Vázoljuk az Ival box példa (§12.4) egy eltérő megvalósítási módját: minden, 
a program által elérhető osztály egyszerűen egy mutatót tartalmazzon a megvaló- 
sító osztályra. Ilyen módon minden , felületosztály" egy megvalósító osztály le- 
írója (handle) lesz, és két hierarchiával fogunk rendelkezni: egy felület- és egy 
megvalósítási hierarchiával. Írjunk olyan részkódokat, amelyek elég részletesek 
ahhoz, hogy bemutassák a típuskonverziókból adódó lehetséges problémákat. 
Gondoljuk át a következő szempontokat: a használat könnyűsége; a programo- 
zás könnyűsége; mennyire könnyű a megvalósító osztályok és a felületek újra- 
hasznosítása, ha új fogalmat vezetünk be a hierarchiába; mennyire könnyű 
változtatásokat eszközölni a felületekben vagy a megvalósításban; és szükség 
van-e újrafordításra, ha változott a rendszerfüggő elemek megvalósítása. 
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9) 


, Az Olvasó idézetének helye." 
(B. Stroustrup) 


Sablonok e Egy karakterlánc sablon e Példányosítás " Sablonparaméterek e Típusellenőr- 
zés s Függvénysablonok e Sablonparaméterek levezetése e Sablonparaméterek meghatá- 
rozása s Függvénysablonok túlterhelése e Eljárásmód megadása sablonparaméterek- 
kel e Alapértelmezett sablonparaméterek e Specializáció s Öröklődés és sablonok s Tag 
sablonok s Konverziók s A forráskód szerkezete s Tanácsok e Gyakorlatok 


13.1. Bevezetés 


Független fogalmakat függetlenül ábrázoljunk és csak szükség esetén használjunk együtt. 
Ha megsértjük ezt az elvet, akkor vagy nem rokon fogalmakat kapcsolunk össze vagy szük- 
ségtelen függéseket teremtünk, így kevésbé rugalmas részekből vagy összetevőkből kell 
majd a programokat összeállítanunk. A sablonok (template) egyszerű módot adnak arra, 
hogy általános fogalmak széles körét ábrázoljuk és egyszerű módon használjuk együtt. 
Az így létrejövő osztályok futási idő és tárigény tekintetében felveszik a versenyt a kézzel 
írott és egyedibb feladatot végző kóddal. 
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A sablonok közvetlenül támogatják az általánosított (generikus) programozást (42.7.), azaz 
a típusoknak paraméterként való használatát. A Ct-4 sablonjai lehetővé teszik, hogy egy 
osztály vagy függvény definiálásakor egy típust paraméterként adjunk meg. A sablon a fel- 
használt típusnak csak azon tulajdonságaitól függ, amelyeket ténylegesen ki is használ. 
A sablon által felhasznált paramétertípusok nem kell, hogy rokonságban álljanak egymás- 
sal, így nem szükséges az sem, hogy egyazon öröklődési hierarchia tagjai legyenek. 


Ebben a fejezetben a sablonokat úgy mutatjuk be, hogy az elsődleges hangsúly a standard 
könyvtár tervezéséhez, megvalósításához és használatához szükséges módszerekre esik. 
A standard könyvtár nagyobb mértékű általánosságot, rugalmasságot és hatékonyságot kö- 
vetel, mint a legtöbb program. Következésképpen a tárgyalandó eljárások széles körben 
használhatóak és igen sokféle probléma megoldásához biztosítanak hatékony segítséget. 
Lehetővé teszik, hogy egyszerű felületek mögé kifinomult megvalósításokat rejtsünk és 
csak akkor , mutassuk be" a bonyolult részleteket a felhasználónak, ha valóban szüksége 
van rájuk. A sort(v) például sokféle tároló objektum tartalmazta sokféle típusú elemnek sok- 
féle rendező algoritmusához adhat felületet. Egy adott v-hez a fordítóprogram automatiku- 
san választja ki a legalkalmasabb rendező függvényt. 


A standard könyvtár minden főbb fogalmat egy-egy sablonként ábrázol (például string, 
ostream, complex, list és map), de a legfőbb műveleteket is, például a karakterláncok 
Cstring-ek) összehasonlítását, a c kimeneti műveletet, a komplex számok (complex) össze- 
adását, egy lista (/isd következő elemének vételét, vagy a rendezést (sortO). Ezért aztán e 
könyvnek az említett könyvtárral foglalkozó fejezetei (a III. rész) gazdag forrásai a sablo- 
nokra és az azokra építő programozási módszerekre vonatkozó példáknak. Következés- 
képpen ez a fejezet a sablonok fogalmát járja körül és csupán a használatuk alapvető mód- 
jait bemutató kisebb példákra összpontosít: 


§13.2 Az osztálysablonok létrehozására és használatára szolgáló alapvető eljárások 
§13.3 Függvénysablonok, függvények túlterhelése, típusok levezetése 

§13.4 Általánosított algoritmusok eljárásmódjának megadása sablonparaméterekkel 
§13.5 Sablon többféle megvalósítása különböző definiciókkal 

§13.6 Öröklődés és sablonok (futási és fordítási idejű többalakúság) 

§13.7 A forráskód szerkezete 


A sablon (template) fogalmát a 4§2.7.1 és a §3.8 pont vezette be. A sablonnevek feloldására, 
illetve a sablonok formai követelményeire vonatkozó részletes szabályok a §C.13 pontban 
vannak. 


13. Sablonok 433 


13.2. Egy egyszerű karakterlánc sablon 


Vegyünk egy karakterláncot. A szring (karakterlánc) olyan osztály, amely karaktereket tárol 
és olyan indexelési, összefűzési és összehasonlítási műveleteket nyújt, amelyeket rendesen 
a ,karakterlánc" fogalmához kötünk. Ezeket különféle karakterkészletek számára szeret- 
nénk biztosítani. Például az előjeles és előjel nélküli, kínai vagy görög stb. karakterekből ál- 
ló láncok számos összefüggésben hasznosak lehetnek. Ezért úgy szeretnénk a karakterlánc 
fogalmát ábrázolni, hogy minél kevésbé függjünk egy adott karakterkészlettől. A karakter- 
lánc definiciója arra épít, hogy egy karaktert le lehet másolni, ezen kívül nem sok egyébre. 
Ezért ha a §11.2-beli char-okból felépülő szring osztályban a karakterek típusát paraméter- 
ré tesszük, általánosabb karakterlánc-osztályt kapunk: 


templatexclass C: class String f 
struct Srep; 
Srep "rep; 

bublic: 
StringO; 
String(const C"); 
String(const Stringf ); 


C read(int i) const; 
SSE 
H 


A templatexcilass C: előtag azt jelenti, hogy egy sablon deklarációja következik és abban 
a Ctípusparamétert fogjuk használni. Bevezetése után a C-t ugyanúgy használhatjuk, mint 
bármely más típusnevet. A C hatóköre a temblatexclass C: előtaggal bevezetett deklaráció 
végéig terjed. Jegyezzük meg, hogy a templatexciass C: előtag azt jelenti, hogy Cegy típus- 
név; nem feltétlenül kell osztálynévnek lennie. Az osztálysablon neve a c: jelpár közé írott 
típusnévvel együtt egy, a sablon által meghatározott osztály nevét adja és ugyanúgy hasz- 
nálható, mint bármely más osztálynév: 


Stringcchar? cs; 
Stringcunsigned char? us; 
Stringcwchar. 12 ws; 


class Jchar f 
// japán karakter 


); 


StringgJchar? js; 
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A névre vonatkozó sajátos formai követelményektől eltekintve a SzringCchar: pontosan 
ugyanúgy működik, mintha a §11.12-beli Szring-definícióval definiáltuk volna. A String sab- 
lonná tétele lehetővé teszi, hogy a char-okból álló karakterláncok szolgáltatásait más típu- 


sú karakterekből álló Szring-ek számára is elérhetővé tegyük. Például ha a standard könyv- 
tárbeli map és String sablonokat használjuk, a §11.8 pont szószámláló példája így írható át: 


int mainO // szavak előfordulásának megszámlálása a bemeneten 


( 
Stringcchar? buj; 
mapcsStringcchar:, int: m; 
while (cin:2buf) mibujfjak; 
// eredmény kiírása 


A Jchar japán karaktereket használó változat ez lenne: 


int mainO // szavak előfordulásának megszámlálása a bemeneten 


( 
StringgJchar: buj; 
mapcsStringxJchar:, int: m; 
while (cin:2buf) mibujfja-k; 
// eredmény kiírása 


A standard könyvtárban szerepel a sablonná alakított String-hez hasonló basic string sab- 
lon is (411.12, §20.39. A standard könyvtárban a string mint a basic stringCchar? szinoni- 
mája szerepel: 


typedef basic stringZchar? string; 


Ez lehetővé teszi, hogy a szószámláló példát így írjuk át: 


int mainO // szavak előfordulásának megszámlálása a bemeneten 
( 

string buj; 

mapsstring, int: m; 

while (cin:2buf) mibujj4-4; 

// eredmény kiírása 


A typedef-ek általában is hasznosak a sablonokból létrehozott osztályok hosszú neveinek 
lerövidítésére. Ráadásul, ha nem érdekel bennünket egy típus pontos definiciója, akkor egy 
typedef elrejti előlünk, hogy sablonból létrehozott típusról van szó. 
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13.2.1. Sablonok meghatározása 


A sablonból létrehozott osztályok teljesen közönséges osztályok, ezért a sablonok haszná- 
lata semmivel sem igényel hosszabb futási időt, mint egy egyenértékű , kézzel írott" osztá- 
lyé, de nem feltétlenül jelenti a létrehozott kód mennyiségének csökkenését sem. 


Általában jó ötlet hibakereséssel ellenőrizni egy osztályt, például a String-et, mielőtt sablont 
készítünk belőle (StringcC2). Ezáltal számos tervezési hibát, a kódhibáknak pedig a leg- 
többjét egy adott osztály összefüggésében kezelhetünk. Ezt a fajta hibakeresést (debugg- 
ing) a legtöbb programozó jól ismeri, és a legtöbben jobban boldogulnak egy konkrét pél- 
dával, mint egy elvonttal. Később aztán anélkül foglalkozhatunk a típus általánosításából 
esetleg adódó problémákkal, hogy a hagyományosabb hibák elvonnák a figyelmünket. Ha- 
sonlóan, ha meg akarunk érteni egy sablont, akkor hasznos annak viselkedését először egy 
konkrét típusú paraméterrel (például a cAhar-ral) elképzelni, mielőtt megpróbáljuk a visel- 
kedését teljes általánosságában megérteni. 


Egy sablon osztály (template class) tagjait ugyanúgy deklaráljuk és definiáljuk, mint a kö- 
zönséges osztályokét. Egy tagot nem szükséges magában az osztályban definiálni; valahol 
máshol is elég, ugyanúgy, mint egy nem sablon osztálytag esetében (4C.13.7.). A sablon 
osztályok tagjai maguk is sablonok, paramétereik pedig ugyanazok, mint a sablon osztályéi. 
Ha egy ilyen tagot az osztályán kívül írunk le, kifejezetten sablonként kell megadnunk: 


templatexclass C2 struct StringZC5::Srep ( 


Cs; // mutató az elemekre 
int Sz; // elemek száma 

int n; // hivatkozásszámláló 
V/ÁBES 


j; 
templatexclass C: C StringZC2::read(int i) const f return rep-slil; ) 


templatexclass C: StringZC5::StringO 
( 


J 


rep - new Srep(O,CO); 


A sablonparaméterek — mint a C — inkább paraméterek, mint a sablonon kívül definiált tí- 
pusok, de ez nem érinti azt a módot, ahogyan az azokat használó sablonkódot írjuk. 
A StringZC: hatókörén belül a cCc-vel való minősítés felesleges, hiszen a sablon neve már 
tartalmazza azt, így a konstruktor neve StringCC2::String lesz. De ha jobban tetszik, meg is 
adhatjuk a minősítést: 
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templatexclass C2 StringZC::StringZC50 


( 
rep - new Srep(O0,CO); 


j 


Egy programban egy tagfüggvényt csak egyetlen függvény definiálhat. Ugyanígy a sablon osz- 
tályok tagfüggvényeit is csak egy függvénysablon definiálhatja. De amíg a függvényeket csak 
túlterhelni lehet (413.3.2), addig a specializációk (413.5) használata lehetővé teszi, hogy egy 
sablonnak több változatát is elkészíthessük. 

Az osztálysablonok neve nem terhelhető túl, így ha egy hatókörben már megadtunk egy 
osztálysablont, ott nem lehet ugyanolyan néven másik egyedet bevezetni (lásd még §13.599: 


templatescilass T: class String €/§ ... "/); 


class String €/5 ... "/);  / hiba: két meghatározás 


A sablonparaméterként használt típusnak biztosítania kell a sablon által várt felületet. 
A String sablon paramétereként használt típusnak például támogatnia kell a szokásos má- 
soló műveleteket (§10.4.4.1, §20.2.10. Jegyezzük meg: az nem követelmény, hogy egy sab- 
lon különböző paraméterei öröklődési viszonyban álljanak egymással. 


13.2.2. Sablonok példányosítása 


Az eljárást, melynek során egy sablon osztályból és egy sablonparaméterből egy osztály- 
deklaráció keletkezik, gyakran sablon-béldányosításnak (template instantiation) hívják 
(4C.13.7.). Ha függvényt hozunk létre egy sablon függvényből és egy sablonparaméterből, 
az a függvény-példányosítás. A sablon adott paramétertípus számára megadott változatát 
specializációnak (specialization) nevezzük. 


Általában az adott C-t fordító és nem a programozó dolga, hogy minden felhasznált para- 
métertípus számára létrehozza a megfelelő sablon függvényt (§C.13.7: 


Stringcchar? cs; 


void JO 
( 


StringgJchar? js; 


cs - "Az adott nyelvi változat feladata, hogy kitalálja, milyen kódot kell létrehozni. "; 


j 
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A fenti esetben a Stringcchar? és a Stringx/Jchar?, a megfelelő Srep típusok, a destruktorok 
és az alapértelmezett konstruktorok, illetve a SiringCchar:::operator-(char ?") deklarációit 
a fordító hozza létre. Más tagfüggvényeket nem használunk, így ilyeneket nem kell készí- 
tenie (remélhetőleg nem is teszi). A létrehozott osztályok közönséges osztályok, így az osz- 
tályokra vonatkozó szokásos szabályok érvényesek rájuk. Ugyanígy a létrehozott függvé- 
nyek is közönséges függvények és a függvényekre vonatkozó szokásos szabályok szerint 
viselkednek. 


Nyilvánvaló, hogy a sablonok hatékony eszközt adnak arra, hogy viszonylag rövid definí- 
ciókból hozzunk létre kódot. Ezért aztán nem árt némi óvatosság, hogy elkerüljük a memó- 
riának csaknem azonos függvény-definiciókkal való elárasztását (413.5). 


13.2.3. Sablonparaméterek 


A sablonoknak lehetnek típust meghatározó, közönséges típusú (pl. ind, és sablon típusú 
paramétereik (§C.13.3). Természetesen egy sablonnak több paramétere is lehet: 


templatecciass T, T def val: class Cont f / ... "/); 


Ahogy a példa mutatja, egy sablonparamétert felhasználhatunk a további sablonparaméte- 
rek meghatározásában is. 


Az egész típusú paraméterek méretek és korlátok megadásánál hasznosak: 


templatecxcliass T, int i2 class Buffer ( 
T ulij; 
int Sz; 
public: 
BujfferO : szi) () 
Mass: 
J; 


BufferSchar, 1272 cbuf; 
BufferSRecord, 82 rbuf; 


A Buffer-hez hasonló egyszerű és korlátozott tárolók ott lehetnek fontosak, ahol a futási 
idejű hatékonyság és a program tömörsége elsődleges szempont, és ahol ezért nem lehet 
az általánosabb szring-et vagy vector-t használni. Mivel a sablon a méretet paraméterként 
megkapja, a kifejtésben el lehet kerülni a szabad tár használatát. Egy másik példa erre 
a Range osztály a §25.6.1-ben. 
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A sablon paramétere lehet konstans kifejezés (4C.5), külső szerkesztésű objektum vagy 
függvény címe (49.2), illetve egy tagra hivatkozó, túl nem terhelt mutató (415.59. A mutató, 
ha sablon paramétereként akarjuk használni, k£ofalakú kell, hogy legyen, ahol ofegy ob- 
jektum vagy függvény neve, illetve falakú, ahol fegy függvény neve. A tagra hivatkozó mu- 
tatókat £ X::of alakban kell megadni, ahol ofa tag neve. Karakterlánc literált nem használ- 
hatunk sablonparaméterként. 


Az egész típusú paramétereknek konstansnak kell lenniük: 


void f(int i) 
f 


Buffersint iz Dx; // hiba: konstans kifejezés szükséges 


j 


Megfordítva, a nem típusba tartozó paraméterek a sablonon belül állandók, így a paramé- 
ter értékének módosítására tett kísérlet hibának számít. 


13.2.4. Típusok egyenértékűsége 


Ha adott egy sablon, akkor különféle paramétertípusok megadásával különféle típusokat 
hozhatunk létre belőle: 


Stringcchar? s1; 
Stringcunsigned char? s2; 
Stringcint- s3; 


typedef unsigned char Uchar; 
StringcUchar? 54; 
Stringcchar? 55; 


BuffersStringcchar:, 102 DI; 
Buffercchar, 102 b2; 
Buffercchar, 20-10: b3; 


Ha azonos paraméterekkel adunk meg sablonokat, azok ugyanarra a létrehozott típusra 
fognak hivatkozni. De mit is jelent itt az, hogy ,azonos"? Szokás szerint, a typedef-ek nem 
vezetnek be új típust, így a SrringcUchar? ugyanaz, mint a StringZunsigned char:. Megfor- 
dítva, mivel a char és az unsigned char különböző típusok (44.39), a Stringcchar: és 
a Stringcunsigned char; is különbözőek lesznek. 


A fordítóprogram ki tudja értékelni a konstans kifejezéseket is (4C.5), így a Buffercchar,20- 
10-2-ről felismeri, hogy a Buffercchar, 102-zel azonos típus. 
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13.2.5. Típusellenőrzés 

A sablonokat paraméterekkel definiáljuk és később így is használjuk. A sablondefinícióban 
a fordítóprogram ellenőrzi a formai hibákat, illetve az olyanokat, amelyek a konkrét para- 
méterek ismerete nélkül felderíthetőek: 


templatecxciass T- class List ( 
struct Link ( 


Link? pre; 
Link" suc; 
T val; 
LTink(tink" p, Link" s,const Tk v) : pre(p), suc(s), val(v) ( ) 
? // szintaktikus hiba: hiányzik a pontosvessző 
Link?" head; 
public: 
ListO : head(7) ( ) // hiba: kezdeti értékadás mutatónak int-tel 
List(const Ig t) : head(new Link(O,o,D)() / hiba: 10" nem definiált azonosító 
Ms 


void print all0 const f for (Link? p - head; b; p-p-2suc) cout ££ p-3val cz Mn; ) 


ő 


A fordítóprogram az egyszerű nyelvi hibákat már a definíciónál kiszűrheti, néha azonban 
csak később, a használatnál. A felhasználók jobban szeretik, ha a hibák hamar kiderülnek, 
de nem minden , egyszerű" hibát könnyű felderíteni. Ebben a példában három hibát vétet- 
tem (szándékosan). A sablon paraméterétől függetlenül egy 7" típusú mutatónak nem ad- 


hatjuk a 7 kezdőértéket. Hasonlóan, az o változó (amely persze egy hibásan írt nulla) nem 
lehet a ListcT:::Link konstruktor paramétere, mert ilyen név az adott pontról nem elérhető. 


A sablon definiciójában használt névnek vagy ismertnek kell lennie, vagy valamilyen éssze- 
rű és nyilvánvaló módon kell függnie valamelyik sablonparamétertől (4C.13.8.1). A T sab- 
lonparamétertől való legközönségesebb és legkézenfekvőbb függés egy 7 típusú tag vagy 
T típusú paraméter használata. A ListcT5::print allÓ példában a cout c£ p-3val kifejezés 
használata némileg , kifinomultabb" példa. 


A sablonparaméterek használatával összefüggő hibák csak a sablon használatának helyén 
deríthetők fel: 


class Recf/ ... "73; 


void fconst Lisizint-k li, const ListcRecx£ Ir) 
f 

li.print allo; 

Irprint allO; 
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Itt a li.brint allO rendben van, de a Ir.brint all0 típushibás, mert a Rec típusnak nincs cc 
kimeneti művelete. A legelső pont, ahol a sablonparaméterek használatával összefüggő hi- 
ba kiderülhet, a sablonnak az adott paraméterrel való első használata. Ezt a pontot rendsze- 
rint első béldányosítási pontnak (first point of instantiation) vagy egyszerűen példányosítási 
bontnak hívják (§C.13.79. Az adott Ct4-változat — megengedett módon - ezt az ellenőrzést 
a program összeszerkesztéséig elhalaszthatja. Ha ebben a fordítási egységben a print all0- 
nak csak a deklarációja és nem a definíciója ismert, lehetséges, hogy az adott fordítónak el 
is kell halasztania a típusellenőrzést a program összeszerkesztéséig (§13.7). A típusellenőr- 
zés azonos szabályok szerint történik, függetlenül attól, hogy melyik ponton megy végbe. 
A felhasználók itt is a minél korábbi ellenőrzést szeretik. A sablonparaméterekre vonatko- 
zó megszorításokat a tagfüggvények segítségével is kifejezhetjük (413.9[16D. 


13.3. Függvénysablonok 


A legtöbb programozó számára a sablonok első számú és legnyilvánvalóbb felhasználása 
olyasféle tároló osztályok létrehozása és használata, mint a basic string (§20.3), a vector 
(416.3), a list (§17.2.2) vagy a map (§17.4.15. Később azonban felmerül a sablonként hasz- 
nált függvények szükségessége. Nézzük például egy tömb rendezését: 


templatexclass T: void sort(vectorST:£ ); // deklaráció 


void f(vectorcint:£ vi, vectorsstring:£ vs) 


( 
sort( vi); // sort(vectorcint2£ ); 
SOTTt(US); // sort(vectorsstring2£ ); 
2 
J 
A sablon függvények (template function) meghívásakor a függvény paraméterei határozzák 
meg, hogy a sablon melyik példányát használjuk, vagyis a sablonparamétereket a függ- 
vényparaméterekből vezetjük le (deduce) (413.3.1. 


Természetesen a sablon függvényt valahol definiálnunk kell (4C.13.79: 


templatexclass T: void sort(vectorST:£ v) // definíció 
// Shell rendezés (Knuth, III. kötet, 84. 02) 
( 


const size tn — v.sizeO; 





2 Magyarul: D. E. Knuth: A számítógép-programozás művészete III. kötet, Keresés és rendezés; Műszaki 
könyvkiadó, Budapest, 1988; 95. oldal 
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for Gint gap-n/2; OSgap; gap/-2) 
for (int i-gap,; izn; it4) 
for Gint j-i-gap; 02-i; j--gap) 
if (uljagapisuljp ( // ulj) és ulj: gap! felcserélése 
T temp — ulj]; 
ulj] - uljagapl; 
uljagap! - temp; 


j 


Hasonlítsuk össze a sort ezen definicióját a §7.7-belivel. Ez a sablonná alakított változat vi- 
lágosabb és rövidebb, mert a rendezendő elemek típusára vonatkozóan több információra 
támaszkodhat. Valószínűleg gyorsabb is, mert nincs szüksége az összehasonlító függvény- 
re hivatkozó mutatóra. Ebből következik, hogy nincs szükség közvetett függvényhívásra, 
a c összehasonlítást pedig könnyen lehet helyben kifejtve (inline) fordítani. 


További egyszerűsítést jelenthet a standard könyvtárbeli swapO sablon használata (§18.6.8), 
mellyel az értékcserét természetes formára alakíthatjuk: 


if Cljagapisulj) swapauljl,uljrgapD; 


Ez a kód hatékonyságát semmilyen módon nem rontja. Ebben a példában a c műveletet 
használtuk összehasonlításra. Nem minden típusnak van azonban c operátora, ami korlá- 
tozza a sort ezen változatának használhatóságát; de ez a korlátozás könnyen megkerülhe- 


tő (413.49. 


13.3.1. A függvénysablonok paraméterei 


A függvénysablonok alapvető fontosságúak a tároló típusok (42.7.2, §3.8, 18. fejezet) széles 
körére alkalmazható általános algoritmusok írásához. Alapvető jelentőségű, hogy egy függ- 
vényhíváskor a sablonparamétereket le lehet vezetni, ki lehet következtetni (deduce) 
a függvény paramétereiből. 


A fordítóprogram akkor tudja levezetni egy hívás típusos és nem típusba tartozó paraméte- 
reit, ha a függvény paraméterlistája egyértelműen azonosítja a sablonparaméterek halmazát 


(4C.13.49: 
templatecxclass T; int iz Tk lookup(BuffersT;izk b, const char" p); 


class Record ( 
const cha[12]; 
VA 

vi 
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Recordk K(BufferSRecord, 1282£ buj; const char? p) 


( 


return lookup(buf p); // lookupO használata, ahol T egy Record és i értéke 128 


J 


Itt 7-ről azt állapítja meg a fordítóprogram, hogy Record, az i-ről pedig azt, hogy értéke 728. 


Megjegyzendő, hogy a fordítóprogram az osztálysablonok paramétereit soha nem vezeti le 
(4C.13.4). Ennek az az oka, hogy az osztályok többféle konstruktora nyújtotta rugalmasság 
ezt sok esetben megakadályozná, esetleg áttekinthetetlenné tenné. Egy osztály különféle 
változatai közötti választásra a specializált változatok használata ad eszközt (413.5)9. Ha egy 
levezett típusú objektumot kell létrehoznunk, ezt sokszor megtehetjük úgy, hogy a létreho- 
zást egy függvény meghívásával hajtatjuk végre (lásd a §17.4.1.2 pontbeli make pairO-D. 


Ha egy paramétert nem lehet levezetni a sablon függvény paramétereiből (4C.13.4), akkor 
közvetlenül meg kell adnunk. Ezt ugyanúgy tehetjük meg, mint ahogy egy sablon osztály 
számára közvetlenül megadjuk a sablonparamétereket: 


templatexclass T: class vector ( /? ... "/ 2; 
// T létrehozása és rá hivatkozó mutató visszaadása 


templatexclass T: T" createO; 


void JO 
( 
vectorsint: v; 
int" p — createsintxO; 


J 


// osztály, sablonbaramétere int" 
// függvény, sablonparamétere int" 


A közvetlen meghatározás (explicit specification) egyik szokásos használata a sablon függ- 


vény visszatérésiérték-típusának megadása: 


templatexciass T, class U2 T implicit cast(U u) (f return u; ) 


void g(int íi) 
( 
implicit cast(i; 
implicit castzdoublex(i); 


implicit castéchar,doublex(i; 
implicit castéchar? intx(0; 


j 


// hiba: T nem vezethető le 
// T típusa double, U típusa int 


// T típusa char, U típusa double 
// T típusa char", U típusa int; hiba: int 
// nem alakítható chart-ra 


Az alapértelmezett függvényparaméter-értékekhez hasonlóan (47.59), az explicit megadott 
sablonparaméterek közül is csak az utolsókat lehet elhagyni. 
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A sablonparaméterek közvetlen megadása átalakító függvénycsaládok és objektum-létre- 
hozó függvények definicióját teszi lehetővé (413.3.2, §C.13.1, $C.13.59. Az automatikus 
(Gmplici)9)) konverziók (§C.6) explicit változatai, például az implicit castO időnként igen 
hasznosak lehetnek. A dynamic cast, static caststb. formai követelményei megfelelnek az 


explicit minősítésű sablon függvényekéinek. A beépített típuskonverziós operátorok azon- 
ban olyan műveleteket támogatnak, amelyeket nem fejezhetünk ki más nyelvi elemmel. 


13.3.2. Függvénysablonok túlterhelése 


Azonos néven több függvénysablon is szerepelhet, sőt ugyanolyan néven több közönséges 
függvény is. A túlterhelt (vagyis azonos névvel mást és mást jelentő) függvények meghívá- 
sakor a megfelelő meghívandó függvény vagy függvénysablon kiválasztásához a túlterhe- 
lés (overloading) feloldása szükséges: 


templatexciass T- T sgrt( D; 
templatexclass T- complexzT: sgrt(complexzT-); 
double sgrt(double); 


void (complexzdouble: Z) 


sgrt(2; // sgrtzintx(inD 
sgrt(2.09; // sgrt(double) 
sgrt(2); // sgrtZzdoublex(complexzdouble:) 


J 


Ahogy a sablon függvény fogalma a függvény fogalmának általánosítása, ugyanúgy a sab- 
lon függvényekre alkalmazandó túlterhelés-feloldási szabályok is a függvényekre alkalma- 
zandó túlterhelés-feloldási szabályok általánosításai. A módszer alapvetően a következő: 
megkeressük minden sablonhoz azt a specializált változatot, amelyik a paramétereknek 
a legjobban megfelel. Ezután ezekre a példányokra és az összes közönséges függvényre is 
a szokásos túlterhelés-feloldási szabályokat alkalmazzuk: 


1. Meg kell keresni azokat a specializált sablon függvény változatokat ($13.2.2), 
amelyek részt fognak venni a túlterhelés feloldásában. Ehhez az összes függ- 
vénysablont megvizsgáljuk, hogy ha más ugyanilyen nevű függvény vagy sab- 
lon függvény nem lenne elérhető, akkor lehetne-e valamilyen sablonparaméter- 
rel alkalmazni. Az sgrt(2) hívás esetében például a következő jelöltek adódnak: 
sgrtizdoublex(complexzdouble:) és sgrtácomplexzdoublez-x(complexzdouble:). 

2. Ha két sablon függvény is meghívható lenne és az egyik specializáltabb a má- 
siknál (413.5.1), akkor a következő lépésekben csak azt vesszük figyelembe. 
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Az sgrt(2) hívás esetében az sgrtcdoublex(complexcdouble:J-t választjuk az 
sgrtccomplexzdoublezx(complexzdouble:) helyett: minden hívás, ami megfelel 
sgrtZT-(complexZTP9-nek, megfelel sgrtcT-( D-nek is. 

3. Ezek után végezzük el a közönséges túlterhelés-feloldást ezen függvényekre és 
a közönséges függvényekre (47.4.). Ha egy sablon függvény paraméterét a sab- 
lonparaméterekből vezettük le (§413.3.1), akkor arra nem alkalmazhatunk kiter- 
jesztést (promotion), illetve szabványos vagy felhasználói konverziót. Az sgrt(2) 
hívás pontosan megfelel az sgrizint-(int9-nek, így azt választjuk a sgrt(double) 
helyett. 

4. Ha egy függvény és egy specializált változata ugyanolyan mértékben megfelelő, 
akkor a függvényt választjuk. Emiatt a sgrt(2.09-hoz a sgrt(doubleJ-t választjuk, 
és nem a sgrizdouble:(double)-t. 

5. Ha nem találunk megfelelő függvényt, akkor a hívás hibás. Ha több ugyanolyan 
mértékben megfelelő függvényt is találunk, akkor a hívás többértelmű és ezért 
hibás: 


templatexclass T- T max(T; D; 


const int s — 7; 


void kO 
( 
max(1,29; // maxcint(1,2) 
maxCa b); // maxxchar:C a, b!) 
max(2.7,4.99; // maxzdouble:(2.7,4.9) 
max(s, 79; // maxzint-(int(5), 7) (egyszerű konverzió) 
maxC a, DD; // hiba: többértelmű (nincs szabványos konverzió) 
max(2.7,4; // hiba: többértelmű (nincs szabványos konverzió) 


J 


A fenti példa két nem egyértelmű hívását explicit minősítéssel oldhatjuk fel: 


void JO 

( 
maxcintxC a, U; // maxcintrx(intCa?), DD 
maxzdoublex(2.7.4; // maxzdouble:(2. 7 double(4)) 


j 


Vagy megfelelő deklarációk alkalmazásával: 


inline int max(int i, int j) ( return maxzintx(i, j); ) 

inline double max(int i, double d) f return maxzdoublec(Ci, 4); ) 

inline double max(double d, int i) f return maxzdouble:(d, 1; ; 

inline double max(double d1, double d2) f return maxzdoublex:(d1,d29; ) 
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void g0 
f 
maxCa,U; — / max(intCa) 1 
max(2.7.4;  / max(2.7,double(4)) 
j 


Közönséges függvényekre a közönséges túlterhelés-feloldási szabályok érvényesek (§7.4), 
és a helyben kifejtés (inline) biztosítja, hogy a hívás nem jár külön , költséggel". 


A max0O függvény igen egyszerű, így explicit módon is írhattuk volna, de a sablon 
specializált használata könnyű és általánosan használható módja az ilyen túlterhelés-felol- 
dó függvények írásának. A túlterhelés-feloldási szabályok biztosítják, hogy a sablon függ- 
vények helyesen működnek együtt az öröklődéssel: 


templatesclass T: class Bf / ... "/); 
templatexclass T: class D : public BZT2€/? ... ?/ 2; 


templatexclass T- void KBS2T2?); 
void g(BXint:? pb, Dcint-" pd) 


JHDD); 7 fsintx(pp) 
HPA); /jfzinte(static castzBzint2tx(pd)); szabványos átalakítás Dsint2t-ról Bzint2t-ra 


J 


Ebben a példában az /ÓO sablon függvény minden 7 típusra elfogadja BC72"-ot. Egy 
Dcint:" típusú paraméterünk van, így a fordítóprogram könnyen jut arra a következtetés- 
re, hogy T-t int-nek véve a hívás egyértelműen feloldható, [(Bsint:"J-ként. Az olyan 
függvényparamétereket, amelyek nem vesznek részt a sablonparaméter levezetésében, 
pontosan úgy kezelhetjük, mint egy nem sablon függvény paraméterét, így a szokásos át- 
konverziók megengedettek: 


templatecxcliass T, class C2 T get nth(Ck p, int n); // az n-edik elem 


Ez a függvény feltételezhetően a C típusú tároló n-edik elemét adja vissza. Minthogy C-t 
a hívás aktuális paraméteréből kell levezetni, az első paraméterre nem alkalmazható 
konverzió, a második paraméter azonban teljesen közönséges, így a szokásos konverziók 
mindegyike tekintetbe vehető: 


class Index f 
bublic: 
operator intO; 
Ms 
Ja 
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void f(vectorcint:kg v, short s, Index i) 


( 
int i1 —- get nthcintx(v,29; // pontos illeszkedés 
int i2 - get nthzintx(1,5); // szabványos konverzió: short-ról int-re 
int i3 - get nthcintx(v,U; // felhasználói konverzió: Index-ről int-re 


13.4. Eljárásmód megadása sablonparaméterekkel 


Gondoljuk meg, hogyan rendezhetjük a karakterláncokat. Három dolog játszik szerepet: a ka- 
rakterlánc, az elemek típusa és a lánc elemeinek összehasonlításakor alkalmazott szempont. 


Nem , betonozhatjuk be" a rendezési elvet a tárolóba, mert az általában nem szabhatja meg, 
mire van szüksége az elemek típusával kapcsolatban, de az elemek típusába sem, mert az 
elemeket sokféle módon rendezhetjük. Ehelyett a megfelelő művelet végrehajtásakor kell 
megadni az alkalmazandó feltételeket. Milyen rendezési elvet alkalmazzunk, ha például 
svéd neveket tartalmazó karakterláncokat akarunk rendezni? A svéd nevek rendezése szá- 
mára a karakterek két különböző numerikus megfeleltetési módja (collating seguence) 
használatos. Természetesen sem egy általános szring típus, sem egy általános rendező algo- 
ritmus nem tudhat a nevek rendezésének , svéd szokásairól", ezért bármely általános meg- 
oldás megköveteli, hogy a rendező eljárást ne csak egy adott típusra adhassuk meg, hanem 
adott típusra való adott alkalmazáskor is. Általánosítsuk például a C standard könyvtárának 
strcmpO függvényét tetszőleges Ttípusból álló Szring-ekre (§13.29: 


templatexciass T; class C: 
int compare(const StringST:£ str1, const StringcT-£ str2) 


( 
JforGint i-O; isstr1.lengthO kg iz str2.lengthO; it) 
if 1C-:egcstrI1lil,str2liD) return C::It(str1li/,str2li)) ? -1 : 1; 
return str1.lengthO-str2.lengthO; 


Ha valaki azt szeretné, hogy a compareO eltekintsen a kis- és nagybetűk közötti különb- 
ségtől vagy figyelembe vegye a program nyelvi környezetét (locale, helyi sajátosságok), ak- 
kor ezt a C::egO és a C::It0 függvények megfelelő definiálásával teheti meg. Ezzel minden 
(összehasonlító, rendező stb.) eljárást leírhatunk, ha az a tároló és a , C-műveletek" nyelvén 
megfogalmazható: 
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templatexcilass T: class Cmp f // szokásos, alapértelmezett összehasonlítás 
bublic: 

static int eg(T a, T b) f return a-b, ) 

static int It(T a, T b) f return aZb; ) 


J; 
class Literate ( // svéd nevek összehasonlítása 
bublic: 
static int eg(char a, char b) f return a-—b; ) 
static int Ilt(char,char); // kikeresés táblázatból karakterérték alapján (§13.X9/140 
J; 


A sablonparaméterek megadásakor most már pontosan megadhatjuk az összehasonlítási 
szabályokat: 


void KStringcchar: swedel, StringCchar: swede2) 


( 


comparex char, Cmpcchar: -(swede1,swede29; 
comparexk char Literate (swede1,swede29; 


J 


Az összehasonlító műveletek sablonparaméterként való megadásának két jelentős előnye 
van az egyéb lehetőségekhez, például a függvénymutatók alkalmazásához képest. Egyrészt 
több művelet megadható egyetlen paraméterként, a futási idő növekedése nélkül. Másrészt, 
az egŐ és az ItO összehasonlító műveleteket könnyű helyben kifejtve (inline) fordítani, míg 
egy függvénymutatón keresztüli hívás ilyen módú fordítása különleges mértékű figyelmet 
követel a fordítóprogramtól. 


Természetesen összehasonlító műveleteket nemcsak a beépített, hanem a felhasználói típu- 
sokra is megadhatunk. Ez alapvető fontosságú feltétele annak, hogy általános algoritmuso- 
kat olyan típusokra alkalmazhassunk, amelyeknek nem maguktól értetődő összehasonlítási 
feltételeik vannak (§18.4). 


Minden osztálysablonból létrehozott osztály saját példányokat kap a sablon statikus válto- 
zóiból (4C.13.1. 

13.4.1. Alapértelmezett sablonparaméterek 

Fáradságos dolog minden egyes hívásnál közvetlenül meghatározni az összehasonlítási fel- 


tételeket. Túlterheléssel szerencsére könnyen megadhatunk olyan alapértelmezést, hogy 
csak a szokásostól eltérő összehasonlítási szempontot kelljen megadni: 
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templatexciass T; class C: 
int compare(const StringST:£ str1, const StringST-£ str2; // összehasonlítás C 
// használatával 


templatezcilass T- 
int compare(const StringST:£ str1, const StringST-£ str29; // összehasonlítás 
// CmprI: használatával 


De a szokásos rendezést megadhatjuk, mint alapértelmezett sablonparaméter-értéket is: 


templatecciass T; class C - CmpsT: 5 
int compare(const StringST:£ str1, const StringcT-£ str2) 


( 
forGint i-O; isstr1.lengthO kg iz str2.lengthO; it) 
if UC::egcstrIlij,str2li)) return C::It(str1Ilil,str2li)) ? -1 : 1; 
return str1.lengthO-str2.lengthO; 


Így már leírhatjuk a következőt: 


void KStringcchar: swedel1, Stringéchar: swede2) 


( 
compare(swede1,swede2)9; // Cmpcchar? használata 


comparecxchar Literatez(swede1,s5wede2); // Ttiterate használata 
? 


J 
Egy (nem svédek számára) kevésbé ezoterikus példa a kis- és nagybetűk közötti különbsé- 
get figyelembe vevő, illetve elhanyagoló rendezés: 


class No casef/ ... 7); 


void KStringcchar? s1, Stringcchar: s2) 


t 
compare(s51,529; // kisbetű-nagybetű különbözik 
comparexchar No. caser(s1,529; // kisbetű-nagybetű nem különbözik 


A standard könyvtár széles körben alkalmazza azt a módszert, hogy az alkalmazandó eljá- 
rásmódot (policy) egy sablonparaméter adja meg, és ennek a legáltalánosabb eljárásmód az 
alapértelmezett értéke (például §18.4). Eléggé furcsa módon azonban a basic string (§13.2, 
20. fejezet) összehasonlításaira ez nem áll. Az eljárásmódot kifejező sablonparamétereket 
gyakran nevezik ,jellemvonásoknak" (traits) is. Például a standard könyvtárbeli szring 
a char. traits-re épül (420.2.1D, a szabványos algoritmusok a bejárók Citerátorok) jellemvo- 
násait (419.2.2), a standard könyvtárbeli tárolók pedig a memóriafoglalókét (allokátor, 
§19.4.) használják fel. 
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Egy alapértelmezett sablonparaméter értelmi ellenőrzése ott és csak akkor történik meg, 
ahol és amikor az alapértelmezett paramétert ténylegesen felhasználjuk. Így ha nem hasz- 
náljuk fel az alapértelmezett CmpcT- paramétert, akkor olyan X típusokra is használhatjuk 
a compareO-t, amelyekre a fordító nem fordítaná le aCmpcX--et, mert mondjuk az X-re a c 
nem értelmezett. Ez döntő jelentőségű a szabványos tárolók tervezésénél, hiszen ezek sab- 
lonparamétert használnak az alapértelmezett értékek megadására (§16.3.4). 


, nun, 


13.5. Specializáció 


Alapértelmezés szerint egy sablon (template) egyetlen definíciót ad a felhasználható által el- 
képzelhető összes paraméterérték (vagy paraméterértékek) számára. Ez azonban nem min- 
den sablon írásakor kedvező. Előfordulhat, hogy olyasmit szeretnénk kifejezni, hogy , ha 
a sablonparaméter egy mutató, használd ezt, ha nem, használd azt", vagy hogy , hiba, ha 
a sablonparaméter nem a My base osztály egy leszármazottjára hivatkozó mutató". Sok ha- 
sonló tervezési szempontot figyelembe lehet úgy venni, hogy a sablonnak többféle 
definíciót adunk és a fordítóprogram az alkalmazott paramétertípusok szerint választ közü- 
lük. A sablon ilyenféle többszörös meghatározását specializációnak (specialization, egyedi 
célú felhasználói változatok használata, szakosítás) hívjuk. 


Vegyük egy Vector sablon valószínű felhasználásait: 


templatexclass T: class Vector f // általános vektortípus 
Tt u; 
int Sz; 
public: 
VectorO; 
Vector(int); 


Ik elemCint i) f return ulij; ? 
Tk operatorf Jint i); 


void swap( Vector ); 
JV asa 
j; 


Vectorcint: ví; 
VectorcShape?t? uvps; 
Vectorsstring: us; 
Vectorcchar"2 upc; 
VectorcNode?2 upn; 
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A legtöbb Vector valamilyen mutatótípus Vector-a lesz. Több okból is, de főleg azért, mert 
a többalakú (polymorpb) viselkedés megőrzése céljából mutatókat kell használnunk 
(42.5.4, §12.2.609. Ezért aki objektumorientált programozást folytat és típusbiztos, például 
standard könyvtárbeli tárolókat használ, az biztosan számos mutatót tartalmazó tárolót fog 
használni. 


A legtöbb C-változat alapértelmezés szerint lemásolja a sablon függvények kódját. Ez jó 
a végrehajtási sebesség szempontjából, de kritikus esetekben (mint az iménti Vector-nál) 
a kód , felfúvódásával" jár. 


Szerencsére létezik egyszerű megoldás. A mutatókat tartalmazó tárolóknak elég egyetlen 
megvalósítás. Ezt specializált változat készítésével érhetjük el. Először definiáljuk a Vector- 
nak a void mutatókra vonatkozó változatát (, specializációját"): 


templates: class Vectorgvoid": ( 
void"? p; 
VEZE 


voidtk operatorf Int i); 
2 


) 
Ezt a változatot aztán az összes, mutatót tartalmazó vektor közös megvalósításaként hasz- 
nálhatjuk. A templates: előtag azt jelenti, hogy ennél a specializált változatnál nem kell sab- 
lonparamétert megadnunk. Azt, hogy milyen típusú sablonparaméterre használjuk, a név 
utáni c2 jelpár között adjuk meg: vagyis a Cvoid?? azt jelenti, hogy ezt a definíciót kell min- 
den olyan Vector esetében használni, amelyikre a 7típusa void". 


A Vectorgvoid?"? egy teljes specializáció, azaz ezen változat használatakor nincs sablonpa- 
raméter, amit meg kellene adni vagy le kellene vezetni; a VectorSvoid":-ot a következő mó- 
don deklarált Vector-ok számára használjuk: 


Vectorgvoid"5 upu; 


Ha olyan változatot akarunk megadni, ami mutatókat tartalmazó Vector-ok, és csak azok 
esetén használandó, részleges specializációra van szükségünk: 


templatexciass T- class VectorST?5 : private Vectorgvoid?: f 
bublic: 
typedef Vectorgvoid?: Base; 


VectorO : BaseO (1? 
explicit VectorGint i) : Base(i) (? 
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Ttk elem(int í) f return reinterpret castzTt8ko-(Base::elem(9; ) 
Tt£k operatorf Int i) ( return reinterpret castZT:k-(Base::operatorf I); ) 


77 zal 
); 


A név utáni c7?5 specializáló minta azt jelzi, hogy ezt a változatot kell minden mutatótípus 
esetében használni; azaz minden olyan sablonparaméternél, ami 7" alakba írható: 


VectorcShapet: ups; [/ £Tt2- most cShape?7, így T is Shape 
Vectorsinttt5 uppi; [/ 2Tt2 most Sinttt5, így T is int? 


Jegyezzük meg, hogy részleges specializáció használata esetén a sablonparaméter 
a specializációra használt mintából adódik; a sablonparaméter nem egyszerűen az aktuális 
sablonparaméter. Így például a VectorcShapet: esetében Ttípusa Shape és nem Shape". 


Ha adott a Vector ezen részlegesen specializált változata, akkor ez az összes mutatótípusra 
vonatkozó Vector közös megvalósítása. A VectorcT": osztály egyszerűen egy felület 
a void"-os változathoz, melyet kizárólag az öröklődés és a helyben kifejtés eszközével va- 
lósítottuk meg. 


Fontos, hogy a Vector ezen finomítása a felhasználói felület megváltoztatása nélkül történt. 
A specializáció a közös felület többféle meghatározásának eszköze. Természetesen az álta- 
lános Vector-t és a mutatókra vonatkozó változatot hívhattuk volna különbözőképpen is. 
Amikor ezt kipróbáltam, kiderült, hogy sok felhasználó, akinek tudnia kellett volna róla, 
mégsem a mutatós változatot használta és a kapott kód a vártnál sokkal nagyobb lett. Eb- 
ben az esetben sokkal jobb a fontos részleteket egy közös felület mögé rejteni. 


Ez a módszer a gyakorlatban a kód felfűvódásának megakadályozásában volt sikeres. Akik 
nem alkalmaznak ilyen módszereket (akár a Cs--ban, akár egyéb típus-paraméterezési le- 
hetőségeket tartalmazó nyelvekben), könnyen azt vehetik észre, hogy az ismétlődő kód kö- 
Zepes méretű programok esetében is megabájtokra rúghat. A vektorműveletek különböző 
változatainak lefordításához szükséges idő megtakarításával ez a módszer a fordítási és 
szerkesztési időt is dc$ámai módon csökkenti. Az összes mutatót tartalmazó lista egyetlen 
specializált változattal való megvalósítása jó példa arra, hogyan lehet a kódfelfúvódást meg- 
akadályozni úgy, hogy a közös kódot a lehető legjobban növeljük. 


Az általános sablont az összes specializált változat előtt kell megadni: 


templatexciass T: class LisizTt2 f/E ... "/); 


templatecxclass T2 class List f/ ... 7); // hiba: általános sablon a specializált után 


452 Absztrakciós módszerek 


Az általános sablon által adott létfontosságú információ az, hogy milyen paramétereket kell 
a felhasználás vagy a specializáció során megadni. Ezért elég az általános sablont a specia- 
lizált változat deklarációja vagy definiciója előtt megadni: 


templatexclass T- class List; 
templatexcilass T: class LiSIZTt2 (/5 ... "/); 


Ha használjuk is, akkor az általános sablont valahol definiálnunk kell (413.79. 


Ha valahol szerepel egy felhasználói specializált változat, akkor annak deklarációja 
a specializált használat minden helyéről elérhető kell, hogy legyen: 


templatexclass T: class List €/§ ... "/); 
Listsinte5 li; 
templatexclass T: class ListzTt2 €/ ... 7); // hiba 


Itt a List-et az int?-ra a Listzint": használata után specializálunk. 


Egy sablon minden specializált változatát ugyanabban a névtérben kell megadni, mint ma- 
gát a sablont. Ha használják, akkor egy explicit deklarált (azaz nem egy általánosabból lét- 
rehozott) sablonnak valahol szintén explicit definiáltnak kell lennie (413.79. Vagyis a specia- 
lizált változat explicit megadásából következik, hogy számára a fordító nem hoz létre 
definíciót. 


13.5.1. Specializációk sorrendje 


Az egyik változat specializáltabb egy másiknál, ha minden olyan paraméterlista, amely il- 
leszkedik az egyikre, illeszkedik a másikra is. Ez fordítva nem áll fenn: 


templatexclass T: class Vector; // általános 
templategclass T: class VectorsT"5; // mutatókhoz 
template: class Vectorgvoid" 5; // voidt-okhoz 


Minden típust használhatunk a legáltalánosabb Vector paramétereként, de a VectorcT": pa- 
ramétereként csak mutatót, a Vectorgvoid"2: paramétereként pedig csak void" mutatót. 
Az objektumok és mutatók stb. (413.5) deklarációjában, illetve a túlterhelés feloldásakor 
(§13.3.2) a leginkább specializált változat részesül előnyben. 
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A specializáló minta megadásánál a sablonparaméterek levezetésénél (413.3.1) használt tí- 
pusokból összeállított típusok használhatók fel. 


13.5.2. Függvénysablon specializáció 


A specializáció természetesen a sablon függvényeknél (template function) is hasznos. Ve- 
gyük a §7.7 és §13.3 példabeli Shell rendezést. Ez az elemeket a — segítségével hasonlítja 
össze és a részletezett kód segítségével cseréli fel. Jobb definíció lenne a következő: 


templatexciass T- bool less(T a, T b) ( return azb; ) 


templatexclass T: void sort( VectorST-£ v) 


( 
const size tn — v.sizeO; 
for (int gap-n/2; OSgap; gap/-2) 
for (int i-gap; izn; iít4) 
for Gint j-i-gap; 0£-j; j-—-gap) 
if ess(ulj:gapl, ulj) ) swapaaljj, vljzgapD; 
j 


Ez nem javítja magát az algoritmust, de lehetőséget nyújt a megvalósítás javítására. Eredeti 
formájában egy Vectorcchar?":-ot nem rendez jól, mert két char"-ot a £ segítségével hason- 
lít össze, azaz az első karakter címét fogja az összehasonlítás alapjául venni. Ehelyett a mu- 
tatott karakterek szerinti összehasonlítást szeretnénk. Erre a less0-nek egy egyszerű, const 
char"-ra vonatkozó specializációja fog ügyelni: 


templates2 bool lesszconst chartr(const char? a, const char? b) 


( 
J 


return strcemp(a,b)2O; 


Mint az osztályoknál is (413.59, a c sablon-előtag azt jelzi, hogy ez egy sablonparaméter 
megadása nélküli specializált változat. A sablon függvény neve utáni cconst char": azt je- 
lenti, hogy a függvényt azokban az esetekben kell alkalmazni, amikor a sablonparaméter 
const char". Minthogy a sablonparaméter közvetlenül levezethető a függvény paraméterlis- 


tájából, nem kell explicit megadnunk. Így egyszerűsíthetünk a specializáció megadásán: 


templates2 bool lesszz(const char? a, const char? b) 


( 
J 


return strcmp(a, b) 20; 
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Minthogy adott a template: előtag, a második, üres c: felesleges, hiszen nem hordoz új 
információt. Így aztán általában így írnánk: 


templates: bool less(const char? a, const char?" b) 


( 


return strcmp(a, b) 20; 


j 


Én jobban kedvelem ezt a rövidebb deklarációs formát. 
Vegyük a swapO kézenfekvő meghatározását: 


templatexclass T: void swap(Ik x, Tk y) 


( 
Tt-x; // x másolása az ideiglenes változóba 
X5EJ; // y másolása x-be 
y-t // ideiglenes változó másolása y-ba 


j 


Ez nem túl hatékony, ha Vector-ok vektoraira hívjuk meg; az összes elem másolásával cse- 
réli fel a Vector-okat. De ezt is megoldhatjuk megfelelő specializációval. Maga a Vector ob- 
jektum csak annyi adatot tartalmaz, hogy az elemeihez való közvetett hozzáférést támogas- 


sa (mint a string §11.12, §13.2). Így aztán a cserét a megfelelő ábrázoló adatok cseréjével le- 


het megoldani. Hogy lehetővé tegyük az ábrázoló adatok kezelését, adjunk meg egy swapO 
függvényt a Vector osztály számára (§13.5): 


templatexclass T: void VectorST:::swap( Vector k a) // ábrázolások cseréje 


( 
swap(v,a.v); 
swap(sz, a.sz); 


J 


A swap tagot felhasználhatjuk az általános swapO specializált definiciójában: 


templatexclass T- void swap(VectorST:k a, VectorcT:£k b) 


( 
a.swap(b); 


J 


A lessŐ és a swapO ezen változatait használja a standard könyvtár (§416.3.9, §20.3.16) is. Rá- 
adásul ezek a példák széles körben használt módszereket mutatnak be. A specializáció ak- 
kor hasznos, ha a sablonparaméterek egy adott halmazára egy általános algoritmusnál léte- 
zik hatékonyabb megvalósítás (itt a swapO). Ezenkívül akkor is hasznos, ha a paramétertí- 
pus valamilyen szabálytalansága miatt a szabványos algoritmus valamilyen nem kívánt mó- 
don működne (mint a less0 esetében). Ezek a , szabálytalan" típusok többnyire a beépített 
mutató- és tömbtípusok. 
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13.6. Öröklődés és sablonok 


Az öröklődés és a sablonok olyan eszközök, amelyekkel meglevők alapján új típusok épít- 
hetők, és amelyekkel általánosságban a közös vonások különféle kihasználásával hasznos 
kód írható. Mint a §3.7.1, §3.8.5 és §13.5 pontokban láttuk, ezen eszközök párosítása sok 
hasznos módszer alapja. 


Egy sablon osztálynak (template class) egy nem sablon osztályból való származtatása mó- 
dot nyújt arra, hogy sablonok egy halmaza közös megvalósításon osztozzék. A §13.5 pont- 
beli vektor jó példa erre: 


templatesclass T: class LiSIZT": : private Listzvoidt2 €/ ... "/); 


Másként nézve a példa azt mutatja, hogy a sablon elegáns és típusbiztos felületet ad egy 
másként nem biztonságosan és nem elegánsan használható eszközhöz. 


Természetesen a sablon osztályok közötti öröklődés is hasznos. A bázisosztály egyik hasz- 
na az, hogy további osztályok számára építőkőül szolgál. Ha a bázisosztály adatai vagy mű- 
veletei valamely származtatott osztály sablonparaméterétől függenek, akkor magának 
a bázisosztálynak is paramétereket kell adni (lásd például a §3.7.2 pontbeli Vec osztály: 


templatecclass T: class vector ( /? ... "/ 3; 
templatexclass T: class Vec : public vectorzT: ( / ... "/ 3; 


A sablon függvények túlterhelés-feloldási szabályai biztosítják a függvények helyes műkö- 
dését az ilyen származtatott típusokra (413.3.2. 


Az az eset a leggyakoribb, amikor ugyanaz a sablonparaméter szerepel a bázis- és a szár- 
maztatott osztályban is, de ez nem szükségszerű. Érdekes, bár ritkábban alkalmazott mód- 
szerek alapulnak azon, hogy magát a származtatott osztályt adjuk át a bázisosztálynak: 


template class C2 class Basic ops f( // tárolók alapbműveletei 

bublic: 
bool operator-—(const C£ ) const; // minden elem összehasonlítása 
bool operator/1-(const C£ ) const; 
Jess 


// hozzáférés biztosítása C műveleteihez 
const Ck derivedO const ( return static castáconst C$g-( this); ) 
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templatexciass T- class Math container : public Basic opsz Math containersT: : ( 
bublic: 

size t size) const; 

Ik operatorl (size D; 

const Ik operatorf ksize 1 const; 


Ms 


Ezáltal lehetővé válik a tárolók alapvető műveleteinek az egyes tárolóktól elkülönített, egy- 
szeri meghatározása. Ám mivel az olyan műveletek definíciójához, mint az —- és a /- mind 
a tárolónak, mind annak elemeinek típusára szükség van, a bázisosztályt át kell adni 


a tárolósablonnak. 


Ha feltesszük, hogy a Math container egy hagyományos vektorra hasonlít, akkor 
a Basic ops egy tagja valahogy így nézhet ki: 


template class C: bool Basic opsZC5::operator-—(const Ck a) const 


if (derivedO.sizeO !"- a.sizeO) return false; 
for (int i - O; izderivedO.sizeO; 441) 

if (derivedO[íJ !- aliJ) return false; 
return true; 


A tárolók és a műveletek elválasztására szolgáló másik módszer öröklődés helyett sablon- 
paraméterekkel kapcsolja össze azokat: 


templatecciass T; class C2 class Mcontainer f 
GC elements; 


bublic: 
Ik operatorl I(size t i) f return elemenis[ij; ) 


as 


friend bool operator-—(const Mcontainerkg , const Mcontainerkg); . // elemek 
// összehasonlítása 


friend bool operator!1-(const Mcontainerk, const Mcontainerg ); 


PE 


); 


templatexclass T: class My array £/7 ... 7); 


Mcontainerk double ,My arrayzdouble: 2 mc; 
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Egy sablonból létrehozott osztály teljesen közönséges osztály, ezért lehetnek barát (friend) 
függvényei (4C.13.2) is. Ebben a példában azért használtam barátokat, hogy a —— és a /- szá- 
mára a két paraméter szokásos felcserélhetőségét biztosítsam (411.3.2)9. Ilyen esetekben 
meg lehetne fontolni azt is, hogy a C paraméterként tároló helyett sablont használjunk. 


13.6.1. Paraméterezés és öröklődés 


A sablonok egy típust vagy függvényt egy másik típussal paramétereznek. A sablon kódja 
minden paramétertípus esetében azonos, csakúgy, mint a sablont használó legtöbb kód- 
rész. Az absztrakt osztályok felületeket írnak le, különféle megvalósításaik kódrészeit az 
osztályhierarchiák közösen használhatják, és az absztrakt osztályt használó kód legnagyobb 
része nem is függ a megvalósítástól. A tervezés szempontjából a két megközelítés annyira 
közeli, hogy közös nevet érdemel. Minthogy mindkettő azt teszi lehetővé, hogy egy algo- 
ritmust egyszer írjunk le és aztán különféle típusokra alkalmazzuk, néha mindkettőt több- 
alakúságnak (polimorfizmus, polymorphism) hívják. Hogy megkülönböztessük őket, a vir- 
tuális függvények által biztosítottat futási idejű (run-time) többalakúságnak, a sablonok ál- 
tal nyújtottat pedig fordítási idejű (compile-time) többalakúságnak vagy paraméteres 
(parametric) többalakúságnak hívják. 


Végül is mikor válasszunk absztrakt osztályt és mikor alkalmazzunk sablont? Mindkét eset- 
ben olyan objektumokat kezelünk, amelyeknek azonos műveleteik vannak. Ha nem szük- 
séges egymással alá- és fölérendeltségi viszonyban állniuk, akkor legyenek sablonparamé- 
terek. Ha az objektumok aktuális típusa a fordítási időben nem ismert, akkor legjobban egy 
közös absztrakt osztályból öröklődő osztályként ábrázolhatjuk azokat. Ha a futási idő na- 


gyon fontos, azaz a műveletek helyben kifejtve történő fordíthatósága alapvető szempont, 
használjunk sablont. Erről részletesebben a §24.4.1 pont ír. 


13.6.2. Tag sablonok 
Egy osztálynak vagy osztálysablonnak lehetnek olyan tagjai is, amelyek maguk is sablonok: 


templatexclass Scalar: class complex ( 
Scalar re, im; 
public: 
templatexclass T- 
complex(const complexzT2g c) : re(c.real0), im(c.imagO) t ) 
Mass 
J; 
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complexsfloat: cj(O,09; 
complexzdouble: cd — cf; // rendben: float-ról double-ra alakítás használata 
class Ouad ( 
// nincs átalakítás int-re 
; 
complexcOuad: cg; 
complexcint: ci — cg; // hiba: nincs átalakítás Ouad-ról int-re 


Vagyis kizárólag akkor tudunk complexcT2:-ből complexcT1--et építeni, ha 77-nek kez- 
dőértékül adhatjuk 72-t, ami ésszerű megszorításnak tűnik. 


Sajnos azonban a Cr nyelv elfogad a beépített típusok közötti bizonyos ésszerűtlen 
konverziókat is, például double-ról int-re. A végrehajtási időben a csonkításból eredő hibákat 
el lehetne kapni, implicit cast (§13.3.1) vagy checked (4C.6.2.6.2) stílusú ellenőrzött 
konverzióval: 


templatexclass Scalar: class complex f 
Scalar re, im; 
bublic: 
complexO : re(0), im(0) f ) 
complex(const complexcScalar:£ c) : re(c.real0), im(c.imagO) tf ) 


templatexclass T22 complex(const complexzT2:£ c) 
: re(checked castSScalar:(c.real0)), im(checked castsScalarr(c.iimagO)) f ) 
Út 


J; 
A teljesség kedvéért alapértelmezett és másoló konstruktort is megadtam. Elég különös 
módon egy sablon konstruktorból a fordító soha nem hoz létre másoló konstruktort, így 
közvetlenül deklarált másoló konstruktor híján a fordító alapértelmezett konstruktort hozott 
volna létre, ami ebben az esetben azonos lett volna az általam megadottal. 


Egy sablon tag nem lehet virtuális: 


class Shape ( 
Z essga 
templatexclass T: virtual bool intersect(const Ik) const -O; // hiba: virtuális sablon 


J; 


Ez szabálytalan. Ha megengedett lenne, akkor a virtuális függvények megvalósításának ha- 
gyományos virtuálisfüggvény-táblás módja (42.5.5) nem lenne alkalmazható. A szerkesztő- 
nek az intersectŐ függvény minden új paramétertípussal történő meghívása esetén egy 


újabb elemmel kellene bővítenie a Shape osztály virtuálisfüggvény-tábláját. 
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13.6.3. Öröklődési viszonyok 


Általában úgy gondolnunk egy sablonra, mint új típusok létrehozását segítő általánosításra. 
Más szóval a sablon egy olyan eszköz, amely szükség esetén a felhasználó előírásai szerin- 
ti típusokat hoz létre. Ezért az osztálysablonokat néha típuskészítőknek vagy típusgeneráto- 


roknak hívják. 


A C44 nyelv szabályai szerint két, azonos osztálysablonból létrehozott osztály nem áll ro- 
konságban egymással: 


class Shape f/£ ... "72; 
class Circle : public Shape ( /? ... "/ 3; 


Ilyenkor egyesek megpróbálják a setcCircle":-ot setcShape":-ként kezelni, ami hibás érve- 
lésen nyugvó súlyos logikai hiba: az ,egy Circle egyben Shape is, így a Circle-ök halmaza 
egyben Shape-ek halmaza is; tehát a Circle-ök halmazát Shape-ek halmazaként is kezelhe- 
tem" érvelés , tehát" pontja hibás. Oka, hogy a Circle-ök halmaza kizárólag Circle típusú ob- 
jektumokat tartalmaz, míg a Shape-ek halmaza esetében ez egyáltalán nem biztos: 


class Triangle : public Shape f /? ... "/ 7; 


void f(setcShapetr-£ 5) 


( 
Ja 
s.insert(new TriangleO); 
VES 

) 


void g(setKCirclet-£k 5) 
( 


HI;  / típushiba: s típusa selKCircle"2, nem setcShape": 
J 


A fenti példát a fordítóprogram nem fogja lefordítani, mert nincs beépített konverzió 
setKCircle?-£k-ről setcShape?t:£-re. Nagyon helyesen. Az a garancia, hogy a setKCircle?": 
elemei Circle-ök, lehetővé teszi, hogy az elemekre biztonságosan és hatékonyan végez- 
zünk Circle-ökre jellemző műveleteket, például a sugár lekérdezését. Ha megengednénk 
a setkCircle":-öknek setcShape":-ként való kezelését, akkor ez már nem lenne biztosított. 
Például az /0 függvény egy Triangle? elemet tesz setcShabpbe?": paraméterébe; ha 
a setcShape?? egy setSCircle?: lehetne, akkor nem lenne többé igaz, hogy egy setcCircle?: 
csak Circle"-okat tartalmaz. 


460 Absztrakciós módszerek 


13.6.3.1. Sablonok konverziója 

Az előző példa azt mutatta be, miért nem lehet semmilyen alapértelmezett kapcsolat két, 
azonos osztálysablonból létrehozott osztály között. Egyes osztályoknál azonban mégiscsak 
szeretnénk ilyen kapcsolatot kifejezni. Például ha egy mutató sablont készítünk, szeretnénk 
tükrözni a mutatott objektumok közötti öröklődési viszonyokat. Tag sablonok (§13.6.2) 
igény esetén sokféle hasonló kapcsolatot kifejezhetnek: 


templatexclass T: class Ptr f // mutató T-re 
D6Di 
bublic: 
PtCT9; 
templatexclass T22 operator PtrST22 O; // PtrST- konverziója Ptr-CI22-re 
Va 


Ezután szeretnénk a konverziós operátorokat úgy definiálni, hogy Ptr-jeinkre fennálljanak 
a beépített mutatóknál megszokott öröklődési kapcsolatok: 


void (PtrxCirclez po 

( 
PtrcShape2 ps - pc; // működnie kell 
PtrxCirclez pc2 - ps; // elvileg hibát eredményez 


J 


Azt szeretnénk, hogy az első kezdőérték-adás csak akkor legyen engedélyezett, ha a Shape 
valóban közvetett vagy közvetlen nyilvános bázisosztálya a Circle-nek. Általában úgy sze- 
retnénk a konverziós operátorokat megadni, hogy a PirST:-ről PtrcT2:-re történő 
konverzió csak akkor legyen engedélyezett, ha egy 72" típusú mutató értékül kaphat egy 
T" típusú mutatót. Ezt így tehetjük meg: 


templatexclass T- 
templatezclass T22 
PtirST2::operator PtrST2? 0 f return PtrcT2x(p9; ; 


A return utasítást a fordító csak akkor fogadja el, ha p (ami 7" típusú) a PtrcT2:x(I29 
konstruktor paramétere lehet. Ezért ha a 7" automatikusan 727-ra konvertálható, a PircT-- 
ről PtrCT25-re történő konverzió működni fog: 


void (PtrxCirclez po 

( 
PtrcShape2 ps - pc; // rendben: Circle? átalakítható Shape"t-ra 
PtrxCirclez pc2 - ps; // hiba: Shape? nem alakítható Circlet-gá 
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Legyünk óvatosak és csak logikailag értelmes konverziókat definiáljunk. 


Jegyezzük meg, hogy nem lehetséges egy sablonnak, illetve annak szintén sablon tagjának 
sablonparaméter-listáit egyesíteni: 


templatecciass T, class T22 // hiba 
PircT5::operator PtrST2? 0 f return PtrcT2x(p9; ) 


13.7. A forráskód szerkezete 


A sablonokat használó kód szerkezete alapvetően kétféle lehet: 


1. A sablonok definícióját beépítjük (include) egy fordítási egységbe, mielőtt hasz- 
nálnánk azokat. 


külön fordítjuk. 


Ezenkívül lehetséges, hogy a sablonfüggvényeket egy fordítási egységen belül először csak 
deklaráljuk, majd használjuk és csak végül definiáljuk. 


Hogy lássuk a kétféle megközelítés közötti különbséget, vegyünk egy egyszerű példát: 
íincludeziostream: 


templatexcilass T- void out(const Ig t) ( std::cerr SZ t; ) 


Hívjuk ezt a fájlt ouwt.c-nek és építsük be, valahányszor szükségünk van az outO-ra: 


// user1.c: 
finclude "out.c" 
// outÓ használata 


// user2.c: 
finclude "out.c" 
// outÓ használata 


Vagyis az outO-ot és a hozzá szükséges valamennyi deklarációt több különböző fordítási 
egységbe is beépítjük. A fordítóprogram dolga, hogy csak akkor hozzon létre kódot, ha 
szükséges, és hogy a felesleges információk feldolgozását optimalizálja, ami azt is jelenti, 
hogy a sablon függvényeket ugyanúgy kezeli, mint a helyben kifejtett (inline) függvényeket. 
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Ezzel az a nyilvánvaló gond, hogy minden olyan információ, amelyre az outO-nak szüksé- 
ge van, az outO-ot felhasználó valamennyi fordítási egységbe belekerül, és ilyen módon 
megnő a fordítóprogram által feldolgozandó adat mennyisége. Egy másik gond, hogy a fel- 
használók esetleg véletlenül , rákapnak" az eredetileg csak az outO definiciójához szüksé- 
ges deklarációk használatára. Ezt a veszélyt névterek használatával, a makrók használatá- 
nak elkerülésével és általában a beépítendő információ mennyiségének csökkentésével há- 
ríthatjuk el. 


E gondolatmenet logikus folyománya a külön fordítás: ha a sablon nem épül be a felhasz- 
nálói kódba, azok az elemek, melyektől függ, nem is befolyásolhatják azt. Így az eredeti 
out.c állományt két részre bontjuk: 


// out.h: 
templatexciass T- void out(const Ik 0; 


// out.c: 
iincludeziostream: 
sinclude "out.h" 


export templatexclass T- void out(const Ig 1) ( std::cerr S£ t; ) 


Az out.c fájl most az outO definiálásához szükséges összes információt tartalmazza, az out.h 
csak a meghívásához szükségeset. A felhasználó csak a deklarációt (vagyis a felületet) épí- 
ti be: 


// user1.c: 
sinclude "out.h" 
// outÓ használata 


// user2.c: 
finclude "out.h" 
// outÓ használata 


Ezen a módon a sablon függvényeket a nem helyben kifejtett függvényekhez hasonlóan ke- 
zeljük. Az ouzt.c-beli definíciót külön fordítjuk, és az adott fordító dolga szükség esetén az 
outO leírásának megkeresése. Ez némi terhet ró a fordítóra, hiszen a sablon-meghatározás 
fölös példányainak kiszűrése helyett szükség esetén meg kell találnia az egyetlen definíciót. 


Jegyezzük meg, hogy a sablon definíciója csak akkor érhető el más fordítási egységből, ha 
kifejezetten export-ként adjuk meg (49.2.3). (Ez úgy történik, hogy a definícióhoz vagy egy 


megelőző deklarációhoz hozzáadjuk az export szót.) Ha nem így teszünk, a definíciónak 
minden használat helyéről elérhetőnek kell lennie. 
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A fordító- és szerkesztőprogramtól, a fejlesztett program fajtájától, illetve a fejlesztés külső 
feltételeitől függ, hogy melyik módszer vagy azok milyen párosítása a legjobb. Általában 
a helyben kifejtett függvényeket és az egyéb, alapvetően más sablon függvényeket hívó 
függvényeket érdemes minden olyan fordítási egységben elhelyezni, ahol felhasználják 
azokat. Egy, a sablon-példányosítás terén átlagos támogatást nyújtó szerkesztőprogram ese- 
tében ez meggyorsítja a fordítást és pontosabb hibaüzenetekhez vezet. 

Ha a definíciót beépítjük, sebezhetővé tesszük azt, mert így értelmét a beépítés helyén ér- 
vényes makrók és deklarációk befolyásolhatják. Ezért a nagyobb vagy bonyolultabb függé- 
seket igénylő sablonokat jobb külön fordíttatni, de akkor is ez az eljárás követendő, ha 
a sablon definiciója sok deklarációt igényel, mert ezek nem kívánatos mellékhatásokkal jár- 
hatnak a sablon felhasználásának helyén. 


Én azt tekintem ideális megoldásnak, ha a sablondefiníciókat külön fordítjuk, a felhaszná- 
lói kódban pedig csak deklarációjukat szerepeltetjük. Ezen elvek alkalmazását azonban 
mindig az adott helyzethez kell igazítanunk, a sablonok külön fordítása pedig egyes nyelvi 
változatok esetében költséges mulatság lehet. 


Bármelyik megközelítést válasszuk is, a nem helyben kifejtett statikus tagoknak (§C.13.1 
csak egyetlen definiciója lehet, valamelyik fordítási egységben. Ebből következően ilyen ta- 
gokat lehetőleg ne használjunk olyan sablonoknál, amelyek sok fordítási egységben szere- 
pelnek. 


Fontos cél, hogy a kód ugyanúgy működjék, akár egyetlen egységben szerepel, akár külön 
fordított egységekbe elosztva. Ezt inkább úgy érhetjük el, hogy csökkentjük a definíció füg- 


gését a környezetétől, nem pedig úgy, hogy a környezetből minél többet átviszünk a pél- 
dányosítás folyamatába. 


13.8. Tanácsok 


[1] Olyan algoritmusok leírására, amelyek sokféle paramétertípusra alkalmazhatók, 
sablont használjunk. §13.3. 

[2] A tárolókat sablonként készítsük el. §13.2. 

[3] A tárolókat specializáljuk mutatótípusokra, hogy csökkentsük a kód méretét. 
§13.5. 


I4] A specializáció előtt mindig adjuk meg a sablon általános formáját. §13.5. 
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[5] 
[6] 


[7] 
[8] 


[91 
[10] 


[11] 


[12] 


[13] 


[14] 


[15] 


[16] 


[17] 


[18] 


[19] 


[20] 


[21] 


Absztrakciós módszerek 


A specializációt deklaráljuk, mielőtt használnánk. 413.5. 

A sablonok függését a példányosítás módjától csökkentsük a lehető legkisebb- 
re. §13.2.5, §C.13.8. 

Definiáljunk minden deklarált specializációt. §13.5. 

Gondoljuk meg, hogy a sablonnak nincs-e szüksége C stílusú karakterláncokra 
és tömbökre vonatkozó specializációkra. §13.5.2. 

Paraméterezzünk eljárásmód objektummal. §13.4. 

Specializáció és túlterhelés segítségével adjunk azonos felületet ugyanazon fo- 
galom különböző típusokra vonatkozó megvalósításának. §13.5. 

Egyszerű esetekre vonatkozóan egyszerű felületet adjunk; a ritkább eseteket 
túlterheléssel és alapértelmezett paraméter-értékekkel kezeljük. §13.5, §13.4. 
Mielőtt sablonná általánosítanánk valamit, végezzünk hibakeresést egy konkrét 
példán. §13.2.1. 

Ne felejtsük el kitenni az exbort kulcsszót azoknál a definícióknál, amelyeket 
más fordítási egységből is el kell érni. §13.7. 

A nagy vagy nem magától értetődő környezeti függőségű sablonokat külön 
fordítási egységben helyezzük el. §13.7. 

Konverziókat sablonokkal fejezzünk ki, de ezeket nagyon óvatosan definiáljuk. 
§13.6.3.1. 

Szükség esetén egy constraintO függvény segítségével korlátozzuk, milyen pa- 
raméterei lehetnek a sablonnak. §13.9[16], §C.13.10. 

A fordítási és összeszerkesztési idővel való takarékoskodás céljából explicit pél- 
dányosítást használjunk. §C.13.10. 

Ha a futási idő döntő szempont, öröklődés helyett használjunk sablonokat. 
§13.6.1. 

Ha fontos szempont, hogy új változatokat újrafordítás nélkül vezethessünk be, 
sablonok helyett használjunk öröklődést. §13.6.1. 

Ha nem lehet közös bázisosztályt megadni, öröklődés helyett használjunk sab- 
lonokat. §13.6.1. 

Ha olyan beépített típusokat és adatszerkezeteket kell használnunk, amelyek- 
nek a korábbi változatokkal összeegyeztethetőnek kell maradniuk, öröklődés 
helyett használjunk sablonokat. §13.6.1. 
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13.9. Gyakorlatok 


1 


o 


11. 


12. 


(2) Javítsuk ki a hibákat a List §13.2.5 pontbeli definiciójában és írjuk meg 

a fordítóprogram által az /O függvény és a List számára létrehozott kóddal 
egyenértékű kódot. Futtassunk le egy egyszerű programot a saját, illetve a sab- 
lonból létrehozott változat ellenőrzésére. Amennyiben módunk van rá, hasonlít- 
suk össze a kétféle kódot. 

(3) Írjunk osztálysablont egy egyszeresen láncolt lista számára, amely egy Link 
típusból származtatott típusú elemeket tud tárolni. A Link típus tartalmazza az 
elemek összekapcsolásához szükséges információkat. Az ilyen listát , tolakodó" 
(intrusive) listának nevezik. Ezen lista felhasználásával írjunk egy bármilyen tí- 
pusú elemeket tartalmazni képes (azaz nem tolakodó) egyszeresen láncolt listát. 
Hasonlítsuk össze a két lista hatékonyságát, előnyeiket és hátrányaikat. 


. (2.5) Írjunk tolakodó és nem tolakodó kétszeresen láncolt listákat. Milyen mű- 


veletek szükségesek az egyszeresen láncolt lista műveletein felül? 


. (2) Fejezzük be a §13.2 pontbeli String sablont a §11.12 pontbeli Sztring osztály 


alapján. 


. (2) Határozzunk meg egy olyan sortO-ot, amely az összehasonlítási feltételt 


sablonparaméterként veszi át. Határozzunk meg egy Record osztályt, melynek 
két tagja van, a count és a price. Rendezzünk egy setéRecord: halmazt mindkét 
tag szerint. 


. (2) Készítsünk egy gsortO sablont. 
. G2) Írjunk egy programot, amely (key, value) párokat olvas be és az egyes kul- 


csokhoz (key) tartozó értékek (value) összegét írja ki. Adjuk meg, milyen típu- 
sok lehetnek kulcsok, illetve értékek. 


. 2.5) A §11.8 pontbeli Assoc osztály alapján készítsünk egy egyszerű Map 


osztályt. A Map működjék helyesen kulcsként használt C stílusú karakterláncok- 
kal és szring-ekkel is, valamint akkor is, ha az alkalmazott típusnak van alapér- 
telmezett konstruktora, és akkor is, ha nincs. 


. 03) Hasonlítsuk össze a §11.8 pontbeli szószámláló program hatékonyságát egy 


asszociatív tömböt nem használó programéval. Azonos stílusú be- és kimeneti 
műveleteket használjunk mindkét esetben. 


. 3) Írjuk át a §13.91(8]-beli Map-et valamilyen alkalmasabb adatszerkezet — pél- 


dául vörös-fekete fa (red-black tree) vagy S-fa (splay tree) — felhasználásával. 
(2.5) Használjuk fel a Map-et topologikus rendezést megvalósító függvény írá- 
sára. (A topologikus rendezést a ÍKnuth, 1987] első kötete írja le, a 280. oldaltól 
kezdődően.) 

(G1.5) A §13.9[71-beli összegző programot javítsuk ki, hogy szóközöket is tartal- 
mazó nevekre is helyesen működjön. 
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13. 2) Írjunk readlineO sablonokat különféle sorfajták számára (például (cikk, 
szám, ár)). 

14. 2) Használjuk a §13.4 pontbeli Literate-ben vázolt módszert karakterláncok 
fordított ábécésorrendű rendezésére. Gondoskodjunk róla, hogy a módszer 
olyan C4--változatokkal is működjön, ahol a char előjeles (signed), és ott is, 
ahol unsigned. Adjunk egy, a kis- és nagybetűk közötti különbséget elhanyago- 
ló rendezést támogató változatot is. 

15.C"1.5) Szerkesszünk egy példát, amely legalább háromféle eltérést mutat be egy 
függvénysablon és egy makró között (a formai követelmények különbségén 
felül. 

16. 2) Tervezzünk egy módszert, amellyel biztosítható, hogy a fordítóprogram 
minden olyan sablon minden paraméterére ellenőrizzen bizonyos megszorításo- 
kat, amelyeknek megfelelő típusú objektum létrejön a programban. Csak ,a T 
paraméternek egy My base-ből származtatott osztálynak kell lennie" típusú 
megszorítások ellenőrzése nem elég! 


14 


Kivételkezelés 


, Ne szóljon közbe, 
amikor éppen közbeszólok." 
(Winston S. ChurchilD 


Hibakezelés s A kivételek csoportosítása s A kivételek elkapása " Minden kivétel elkapá- 
sa e Továbbdobás e Az erőforrások kezelése s auto ptr s A kivételek és a new operá- 
tor e Az erőforrások kimerülése s Kivételek konstruktorokban s Kivételek destruk- 
torokban s Olyan kivételek, amelyek nem hibák " Kivételek specifikációja ? Váratlan kivé- 
telek s El nem kapott kivételek s A kivételek és a hatékonyság " A hibakezelés egyéb mód- 
jai s Szabványos kivételek 9 Tanácsok e Gyakorlatok 


14.1. Hibakezelés 


Ahogy a §8.3 pontban rámutattunk, egy könyvtár szerzője felfedezheti a futási idejű hibá- 
kat, de általában fogalma sincs róla, mit kezdjen velük. A könyvtár felhasználója tudhatja, 
hogyan kell az ilyen hibákat kezelni, de nem tudja felderíteni azokat — máskülönben a fel- 
használói kódban kezelné és nem a könyvtárnak kellene megtalálnia őket. A kivételek 
(exception) az ilyen problémák kezelését segítik. Az alapötlet az, hogy ha egy függvény 
olyan hibát talál, amelyet nem tud kezelni, akkor egy kivételt vált ki ( kivételt dob", throw) 
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abban a reményben, hogy a (közvetett vagy közvetlen) hívó képes kezelni a problémát. 
Az adott problémát kezelni tudó függvények jelezhetik, hogy el akarják kapni (catch) a ki- 
vételt (42.4.2, 48.39. 


A hibakezelés ezen módja felveszi a versenyt a hagyományosabb módszerekkel. Tekintsük 
át a többi lehetőséget: ha a program észreveszi, hogy olyan probléma lépett fel, amelyet 
nem lehet helyben megoldani, akkor 


1. befejezheti a program futását, 

2. egy ,hiba" jelentésű értéket adhat vissza, 

3. egy normális értéket adhat vissza és a programot , szabálytalan" állapotban 
hagyhatja, 

4. meghívhat egy, , hiba" esetén meghívandó függvényt. 


Alapértelmezés szerint az első eset, azaz a program futásának befejezése történik, ha olyan 
kivétel lép fel, amelyet nem kap el a program. A legtöbb hiba kezelésére ennél jobb meg- 
oldás szükséges és lehetséges. Azok a könyvtárak, amelyek nem ismerik a befoglaló prog- 
ram célját vagy annak általános működését, nem hajthatnak végre egyszerűen egy abortO- 
ot vagy exit0-et. Olyan könyvtárat, amely feltétel nélkül befejezi a program futását, nem 
használhatunk olyan programban, amelynek nem szabad , elszállnia". A kivételek szerepét 
tehát úgy is megfogalmazhatnánk, hogy lehetőséget adnak arra, hogy a vezérlés visszake- 
rüljön a hívóhoz, ha a megfelelő művelet helyben nem végezhető el. 


A második eset ( hiba jelentésű érték visszaadása") nem mindig kivitelezhető, mert nem 
mindig létezik elfogadható , hibát jelentő érték". Ha egy függvény például int típussal tér 
vissza, akkor minden int érték hihető visszatérési érték lehet. De ha alkalmazható is ez 
a módszer, sokszor akkor is kényelmetlen, mert minden hívást ellenőrizni kell, ami a prog- 
ram méretét akár kétszeresére is növelheti (414.8). Ezért aztán ezt a módszert ritkán alkal- 
mazzák annyira következetesen, hogy minden hibát észleljenek vele. 


A harmadik módszer ( normális érték visszaadása és a program szabálytalan állapotban va- 
ló hagyása") azzal a gonddal jár, hogy a hívó esetleg nem veszi észre, hogy a program nem 
megengedett állapotba került. A C standard könyvtárának számos függvénye például az 
errno globális változót állítja be, hogy hibát jelezzen (414.8), a programok azonban jellem- 
zően elmulasztják az errno változó kellően következetes vizsgálatát, ami megakadályozná 
a hibás hívások halmozódását. Ezenkívül az egyidejű hozzáférésnél (konkurrencia, 
concurrency) a globális változók hibajelzésre való használata nem működik jól. 
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A kivételkezelés nem az olyan esetek kezelésére szolgál, mint amelyekre a negyedik, a , hi- 
bakezelő függvény meghívása" mód alkalmas, kivételek híján viszont a hibakezelő függ- 
vénynek csak a többi három lehetősége van a hiba kezelésére. A hibakezelő függvények és 
a kivételek témáját a §14.4.5 pont tárgyalja. 


A kivételkezelést akkor célszerű használnunk a hagyományos módszerek helyett, ha azok 
nem elégségesek, nem , elegánsak" vagy hibákat okozhatnak. A kivételek használata lehe- 
tővé teszi a hibakezelő kódnak a közönséges" kódtól való elválasztását, ezáltal a progra- 
mot olvashatóbbá és a kódelemző eszközök számára kezelhetőbbé teszi. A kivételkezelő 
eljárás szabályosabb hibakezelést tesz lehetővé és megkönnyíti a külön megírt kódrészek 
közötti együttműködést. 


A C44 kivételkezelésének a Pascal- és C-programozók számára új vonása, hogy a hibák 
(különösen a könyvtárakban fellépett hibák) alapértelmezett kezelése a program leállítása. 
A hagyományos kezelés az volt, hogy valahogy átevickéltünk a hibán, aztán reményked- 
tünk. A kivételkezelés törékenyebbé teszi a programot abban az értelemben, hogy több 
gondot és figyelmet kell fordítani arra, hogy a program elfogadhatóan fusson. Mindazonál- 
tal ez előnyösebbnek tűnik, mintha később a fejlesztés során lépnének fel hibás eredmé- 
nyek, vagy akár a fejlesztés lezárulta után, amikor a program már a mit sem sejtő felhaszná- 
lók kezében van. Ha a leállás az adott programnál elfogadhatatlan, akkor el lehet kapni az 
összes kivételt (§14.3.2) vagy az összes adott fajtájút (414.6.2), így a kivétel csak akkor állít- 
ja le a programot, ha a programozó ezt hagyja. Ez pedig jobb, mint ha a hiba hagyományos 
módon történt , nem teljes" kezelését követően végzetes hiba, majd feltétel nélküli leállás 
történne. 


Egyesek a hibákon való , átevickélés" nem vonzó tulajdonságait hibaüzenetek kiíratásával, 
a felhasználó segítségét kérő ablakokkal stb. próbálták enyhíteni. Az ilyesmi főleg a prog- 
ram hibakeresésénél (debugging, ,a program belövése") hasznos, amikor a felhasználó 
a program szerkezetét ismerő programozó. Nem fejlesztők számára az esetleg jelen sem le- 
vő felhasználó/kezelő segítségét kérő könyvtár elfogadhatatlan. Ezenkívül sokszor nincs is 
hová értesítést küldeni a hibáról (például ha a program olyan környezetben fut, ahol a cerr 
nem vezet a felhasználó által elérhető helyre), és a hibaüzenetek a végfelhasználó számára 
úgysem mondanának semmit. Az a legkevesebb, hogy a hibaüzenet esetleg nem is a meg- 
felelő nyelven jelenne meg, mondjuk finnül egy angol felhasználó számára. Ennél rosszabb, 
hogy a hibaüzenet jellemzően a könyvtár fogalmaival lenne megfogalmazva, mondjuk egy 
grafikus felhasználói felületről érkezett rossz adat hatására ,bad argument to atan2". Egy jó 
könyvtár nem , halandzsázik" így. A kivételek lehetővé teszik az adott kódrészlet számára, 
hogy a hibát, amit nem tud kezelni, a kód olyan része számára továbbítsa, amely talán bol- 
dogul vele. A programnak csak olyan része lehet képes értelmes hibaüzenet küldésére, 


amelynek van fogalma a program összefüggéseiről, környezetéről. 
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A kivételkezelésre úgy is tekinthetünk, mint a fordítási idejű típusellenőrzés és többértel- 
műség-kiszűrés futási idejű megfelelőjére. A tervezési folyamatra nagyobb hangsúlyt helyez 
és megnövelheti egy kezdeti (még hibás) változat előállításához szükséges munka mennyi- 
ségét. Ám az eredmény egy olyan kód, amelynek sokkal nagyobb az esélye arra, hogy az 
elvárt módon fusson, hogy egy nagyobb program része lehessen, hogy más programozók 
számára is érthető legyen, hogy eszközökkel lehessen kezelni. Ennek megfelelően a kivé- 
telek nyelvileg támogatott kezelése kifejezetten támogatja a , jó stílusú" programozást, mint 
ahogy a C4t- nyelv más eszközei támogatják azt. Más nyelveken (C vagy Pascal) a jó stílus 
csak egyes szabályok , megkerülésével" és nem is tökéletesen érhető el. 


Meg kell azonban jegyeznünk, hogy a hibakezelés ezután is nehéz feladat marad és a kivé- 
telkezelő eljárás — jóllehet rendszerezettebb, mint azok a módszerek, amelyeket helyette- 
sít — a vezérlést kizárólag helyben szabályozó nyelvi elemekhez képest kevésbé hatékony. 
A C44 nyelv kivételkezelése a programozónak a hibák azon helyen való kezelésére ad le- 
hetőséget, ahol ez a rendszer szerkezetéből adódóan a legtermészetesebb. A kivételek nyil- 
vánvalóvá teszik a hibakezelés bonyolultságát, de vigyázzunk, hogy a rossz hírért ne annak 
hozóját hibáztassuk. Ezen a ponton célszerű újraolvasni a §8.3 pontot, amely a kivételkeze- 
lés alapvető vonásait mutatja be. 


14.1.1. A kivételek más megközelítései 


A , kivétel" (exception) azon szavak egyike, amelyek különböző emberek számára külön- 
böző jelentéssel bírnak. A Ct-4 nyelv kivételkezelő rendszerét úgy tervezték, hogy hibák és 
más kivételes jelenségek kezelését támogassa — innen a neve - és hogy támogassa a hibák 
kezelését függetlenül fejlesztett összetevőkből álló programokban. 


A kivételkezelés csak a szinkron kivételek, például a tömbindex-hibák vagy ki- és bemene- 
ti hibák kezelésére szolgál. Az aszinkron események, mint a billentyűzet felől érkező meg- 
szakítások vagy bizonyos aritmetikai hibák nem feltétlenül kivételek és nem közvetlenül 
ezzel az eljárással kezelendők. Az aszinkron események világos és hatékony kezeléséhez 
a kivételkezelés itt leírt módjától alapvetően különböző eljárásokra van szükség. Sok rend- 
szernek vannak az aszinkronitás kezelésére szolgáló eljárásai (például szignálok (jelzések, 
signal) használata), de mivel ezek rendszerfüggőek szoktak lenni, leírásuk itt nem szerepel. 


A kivételkezelés egy nem lokális, a (végrehajtási) verem ,visszatekerésén" (stack 
unwinding, §14.4) alapuló vezérlési szerkezet, amelyet alternatív visszatérési eljárásként is 
tekinthetünk. Ezért kivételeket olyan esetekben is szabályosan alkalmazhatunk, amelyek- 
nek semmi közük a hibákhoz (§14.5). A kivételkezelésnek azonban a hibakezelés és a hi- 


batűrő viselkedés támogatása az elsődleges célja és ez a fejezet is ezekre összpontosít. 
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A szabványos C4-4 nem ismeri a végrehajtási szál (thread) és a folyamat (process, processz) 
fogalmát, ezért az egyidejű hozzáféréssel összefüggő kivételes helyzeteket itt nem tárgyal- 
juk. A használt rendszer dokumentációja leírja az ezeket kezelő eszközöket; itt csak azt 
jegyzem meg, hogy a C-t nyelv kivételkezelő rendszerét úgy tervezték, hogy konkurens 
programban is hatékony legyen, feltéve, hogy a programozó vagy a rendszer betart bizo- 
nyos alapvető szabályokat, például azt, hogy szabályosan zárolja (ock) a megosztott adat- 
szerkezeteket a használat előtt. 


A C44 kivételkezelő eljárásainak a hibák és kivételes események jelentése és kezelése a cél- 
juk, de a programozónak kell eldöntenie, hogy egy adott programban mi számít kivételes- 
nek. Ez nem mindig könnyű (§14.5). Tekintsünk-e kivételesnek egy olyan eseményt, amely 
a program legtöbb futásakor fellép? Lehet-e egy tervezett és kezelt esemény hiba? Mindkét 
kérdésre igen a válasz. A , kivételes" nem azt jelenti, hogy , szinte soha nem történhet meg" 
vagy hogy , végzetes". Jobb úgy értelmezni a kivételt, hogy ,a rendszer valamely része nem 
tudta megtenni, amire kérték". Szokás szerint ilyenkor valami mással próbálkozunk. Kivé- 
telek kiváltása ( dobása") a függvényhívásokhoz képest ritkán forduljon elő, különben 
a rendszer szerkezete áttekinthetetlen lesz. A legtöbb nagy program normális és sikeres fut- 
tatása során azonban néhány kivétel kiváltása és elkapása biztosan elő fog fordulni. 


14.2. A kivételek csoportosítása 


A kivétel olyan objektum, melynek osztálya valamilyen kivétel előfordulását írja le. A hibát 
észlelő kód (általában egy könyvtár) , eldobja" (throw) az objektumot (48.39). A hibát kezel- 
ni képes kódrészlet beavatkozási szándékát egy , elkapó" (catc/) záradékkal jelzi. A kivétel 
, eldobása" , visszatekeri" a végrehajtási vermet, egészen addig, amíg egy megfelelő (vagyis 
a kivételt kiváltó függvényt közvetve vagy közvetlenül meghívó) függvényben catcA-et 
nem találunk. 


A kivételek gyakran természetes módon családokra oszthatók. Ebből következőleg a kivé- 
telek csoportosításához és kezeléséhez az öröklődés hasznos segítséget nyújthat. Egy ma- 
tematikai könyvtár kivételeit például így csoportosíthatjuk: 


class Matherr £ ); 

class Overflow: public Matherr f ; ; 
class Underflow: public Matherr f ?;; 
class Zerodivide: public Matherr f ?; ; 
41 vs 
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Ez a szerkezet lehetővé teszi, hogy a pontos típusra való tekintet nélkül kezeljünk bármi- 
lyen Matherr-t: 


void JO 
( 
try ( 
Z égs 


j 


catch (Overflow) ( 


// az Overflow (túlcsordulás) vagy más onnan származó hiba kezelése 


J 


catch (Matherr) ( 


// nem Overflow matematikai (Matherr) hibák kezelése 


J 


j 


Itt az Overflow-t külön kezeltük. Az összes többi Matherr kivételt az általános záradék fog- 
ja kezelni. A kivételeknek hierarchiába való szervezése fontos lehet a kód tömörsége céljá- 
ból. Gondoljuk meg például, hogyan lehetne a matematikai könyvtár összes kivételét 
kezelni, ha nem volnának csoportosítva. Az összes kivételt fel kellene sorolni: 


void g0 
( 
try ( 
9/4598 


4 


J 
catch (Overflow) £ / ... "/) 

catch (Underflow) £ /? ... "/) 
catch (Zerodivide) ( / ... "/ ) 


Ez nemcsak fárasztó, de egy kivétel könnyen ki is maradhat. Gondoljuk meg, mi lenne, ha 
nem csoportosítanánk a matematikai kivételeket. Ha a matematikai könyvtár egy új kivétel- 
lel bővülne, minden, az összes kivételt kezelni kívánó kódrészletet módosítani kellene. Ál- 
talában a könyvtár első változatának kibocsátása után ilyen teljes körű módosításokra nincs 
mód. De ha van is, nem biztos, hogy minden kód a rendelkezésünkre áll, vagy ha igen, nem 
biztos, hogy tényleg hajlandóak vagyunk átdolgozni. Ezek az újrafordítási és módosítható- 
sági szempontok ahhoz az irányelvhez vezetnének, hogy az első változat kibocsátása után 
a könyvtár nem bővülhetne további kivételekkel; ez pedig a legtöbb könyvtár számára el- 
fogadhatatlan. Ezért tehát a kivételeket célszerű könyvtárankénti vagy alrendszerenkénti 
csoportokban megadni (414.6.2). 
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Jegyezzük meg, hogy sem a beépített matematikai műveletek, sem a (C-vel közös) alapve- 
tő matematikai könyvtár nem kivételek formájában jelzik az aritmetikai hibákat. Ennek 
egyik oka, hogy számos utasításcsövet alkalmazó (pipelined) rendszer aszinkron módon 
észlel bizonyos aritmetikai hibákat, például a nullával való osztást. A Matherr hierarchia 
ezért itt csak illusztrációul szolgál. A standard könyvtárbeli kivételeket a §14.10 írja le. 


14.2.1. Származtatott kivételek 


Az osztályhierarchiák kivételkezelésre való használata természetesen vezet olyan kivételke- 
zelőkhöz, amelyeket a kivételek hordozta információnak csak egy része érdekel. Vagyis egy 
kivételt általában egy bázisosztályának a kezelője kap el, nem saját osztályának kezelője. 
A kivétel elkapásának és megnevezésének működése a paraméteres függvényekével azo- 
nos. Vagyis a formális paraméter a paraméter-értékkel kap kezdőértéket (47.29. Ebből kö- 
vetkezik, hogy a kivételnek csak az elkapott osztálynak megfelelő része másolódik le (fel- 
szeletelődés, slicing, §12.2.39: 


class Matherr f 
ezé 
virtual void debug printO const f( cerr SZ "Matematikai hiba"; ? 


); 


class Int overflow: public Matherr ( 
const char? op; 
int al, a2; 
bublic: 
Int overflou(const char"? p, int a, int b) f op - p; a1 -— a; a2 - b; ) 
virtual void debug printO const ( cerr SZ op cz (" cz al cz )! cz a2 cz 9; ) 


VAA 
J; 
void JO 
( 
try ( 
20; 
j 
catch (Matherr m) f 
162, 
j 
j 


A Matherr kezelőbe való belépéskor az m egy Matherr objektum, még ha gŐ egy 
Int overflow-t váltott is ki. Következésképpen az Int overflow-ban levő többlet információ 
elérhetetlen. 
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Mint mindig, mutatók vagy referenciák használatával megakadályozhatjuk az információ- 
vesztést: 


int addGint x, int y) 


t 
if ((xx0 k.k yP0 kk x:INT. MAX-y) 11 (xc0 ££ yc0 kk XxZINT. MIN-y)) 
throw Int overflowC4" x,y); 
return xty; — // xty nem fog túlcsordulni 
J 
void JO 
t 


try ( 
int il — add(1,29; 
int i2 - addaNT. MAX, -2); 
int i3 - adddNT. MAX, 29; // ez az! 


J 


catch (Matherrg m) ( 
Mesés 
m.debug printO; 


Az utolsó addÓ hívás kiváltotta kivétel hatására Int overflow::debug printO fog végrehaj- 
tódni. Ha a kivételt érték és nem referencia szerint kaptuk volna el, akkor ehelyett 
Matherr::debug printO-re került volna sor. 


14.2.2. Összetett kivételek 


Nem minden kivételcsoport fa szerkezetű. Egy kivétel gyakran két csoportba is tartozik: 


class Netfile err : public Network err, public File system err(/? ... "/ 3; 


Egy ilyen Netfile err -t el lehet kapni a hálózati kivételekkel törődő függvényekben: 


void JO 
( 
try ( 
// valami 


J 


catch(Network errg e) ( 
Ide 


J 


3 
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De akár a fájlrendszer-kivételekkel foglalkozó függvényekben is: 


void g0 
( 


try ( 
// valami más 


catch(File system errg e) ( 
eze 
) 
) 


A hibakezelés ilyen nem hierarchikus szervezése akkor fontos, amikor a szolgáltatások 
(például a hálózati szolgáltatások) a felhasználó számára láthatatlanok. Ebben a példában 
a g0 írója esetleg nem is tudott arról, hogy hálózat is szerepet játszik (lásd még §14.0). 


14.3. A kivételek elkapása 


Vegyük az alábbi kódrészletet: 


void JO 
f 
try ( 
throw EO; 
J 
catch(TD ( 


// mikor jutunk ide? 


J 
J 


A vezérlés akkor kerül a kezelőhöz, ha 


H ugyanaz a típus, mint E, 

H egyértelmű bázisosztálya E-nek, 

H és E mutatótípusok és a mutatott típusokra teljesül 1. vagy 2., 
H referencia és típusára teljesül 1. vagy 2. 


iazzolás ző sZ sej 
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Ezenkívül egy kivétel elkapásánál ugyanúgy alkalmazhatjuk a const minősítőt, mint egy 
függvény paraméterénél. Ettől az elkapható kivételek típusa nem változik meg, csak meg- 
akadályozza, hogy az elkapott kivételt módosíthassuk. 


Az az elv, hogy a kivételről kiváltásakor másolat készül, a kezelő pedig az eredeti kivétel 
másolatát kapja meg. Lehetséges, hogy egy kivételről elkapása előtt több másolat is készül, 
ezért nem lehet olyan kivételt kiváltani, ami nem másolható. Az adott nyelvi változat na- 
gyon sokféle módszert alkalmazhat a kivételek tárolására és továbbítására, de az biztosított, 
hogy a memória elfogyásakor szabványos módon kiváltandó kivétel, a bad alloc (§14.4.5) 
számára van hely. 


14.3.1. A kivételek továbbdobása 


Gyakran előfordul, hogy miután egy kezelő elkapott egy kivételt, úgy dönt, hogy nem tudja 
teljes egészében kezelni azt. Ilyenkor a kezelő általában megteszi helyben, amit lehet, majd 
továbbdobja a kivételt. Így a hibát végül is a legalkalmasabb helyen lehet kezelni. Ez akkor 
is igaz, ha a kivétel kezeléséhez szükséges információ nem egyetlen helyen áll rendelkezés- 


re és a hiba következményeit legjobban több kezelő között elosztva küszöbölhetjük ki: 


void hO 
( 
tryt 
// esetleg matematikai hibákat kiváltó kód 
2 
J 
catch (Matherr) f 
if (eljesen le tudjuk kezelni) f 
// Matherr kezelése 


return; 
2 


else ( 
// megtesszük, amit lehet 


throw; // a kivétel továbbdobása 


A kivétel továbbdobását az operandus nélküli tArow jelzi. Ha akkor próbálunk meg kivételt 
továbbdobni, ha nincs is kivétel, terminate0 hívás fog bekövetkezni (414.7). A fordítóprog- 
ram az ilyen esetek egy részét — de nem mindet - felderítheti és figyelmeztethet rájuk. 
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A továbbdobás az eredeti kivételre vonatkozik, nem csak annak elkapott részére, ami 
Matherr-ként rendelkezésre áll. Más szóval, ha a program Int overflow-t váltott ki, amelyet 
hO egy Matherr-ként kapott el és úgy döntött, hogy továbbdobja, akkor a hO hívója is 
Int overflow-t kap. 


14.3.2. Minden kivétel elkapása 


Az elkapási és továbbdobási módszer egy végletes esetével is érdemes megismerkednünk. 
Mint ahogy függvényekre a ... tetszőleges paramétert jelent (47.69), a catchC ..) jelentése is 
a tetszőleges kivétel elkapása: 


void mO 
( 


try ( 
// valami 


j 

catch (...)( // minden kivételt elkapbunk 
// takarítás 
throw; 


Így ha mO fő részének végrehajtása során bármilyen kivétel lép fel, sor kerül a kezelő függ- 
vény rendrakó tevékenységére. Amint a helyi rendrakás megtörtént, az arra okot adó kivé- 
tel továbbdobódik a további hibakezelés kiváltása céljából. A §14.6.3.2 pont ír arról, hogyan 
lehet információhoz jutni a ... kezelő által elkapott kivételről. 


A hibakezelésnek általában (a kivételkezelésnek pedig különösen) fontos szempontja 
a program által feltételezett állapot érvényességének megőrzése (invariáns, §24.3.7.19. Pél- 
dául ha mO bizonyos mutatókat olyan állapotban hagy hátra, ahogy azokat találta, akkor 
a kivételkezelőbe beírhatjuk a nekik elfogadható értéket adó kódot. Így a ,minden kivételt 
elkapó" kezelő tetszőleges invariánsok kezelésére alkalmas hely lehet. Sok fontos esetben 
azonban egy ilyen kivételkezelő nem a legelegánsabb megoldás (lásd §14.4). 
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14.3.2.1. A kezelők sorrendje 


Mivel egy származtatott osztályú kivételt több típusú kivétel kezelője is elkaphat, a try utasí- 
tásban a kezelők sorrendje lényeges. A kezelők kipróbálására ebben a sorrendben kerül sor: 


void JO 
( 
try ( 
HZ 


j 


catch (std::ios base::failure) f( 
// í/o adatfolyam hibák kezelése (§14.10) 


J 


catch (std::exceptionk e) f 
// standard könyvtárbeli kivételek kezelése (§14.10) 
2 


J 
catch (...) ( 


// egyéb kivételek kezelése (§14.3.2) 


J 


j 


Mivel a fordítóprogram ismeri az osztályhierarchiát, sok logikai hibát kiszűrhet: 


void g0 
( 
try( 
1 szg 
) 
catch (...) ( 


// minden kivétel kezelése (§14.3.2) 


J 


catch (std::exceptionk e) f 
// standard könyvtárbeli kivételek kezelése (§14.10) 
2 
J 
catch (std::bad cast) ( 


// dynamic. cast hibák kezelése (§15.4.2) 


j 


J 


Itt az exception soha nem jut szerephez. Még ha el is távolítjuk a mindent elkapó kezelőt, 
a bad cast akkor sem kerül szóba, mert az exception leszármazottja. 
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14.4. Erőforrások kezelése 


Amikor egy függvény lefoglal valamilyen erőforrást — például megnyit egy fájlt, lefoglal va- 
lamennyi memóriát a szabad tárban, zárol valamit stb. —, gyakran fontos feltétel a rendszer 
további működése szempontjából, hogy az erőforrást rendben fel is szabadítsa a hívóhoz 
való visszatérés előtt: 


void use file(const char? fm) 
FILE? f - fopen(fn, "r); 
// f használata 


Jfelose(D; 
J 


Ez működőképesnek tűnik, amíg észre nem vesszük, hogy ha valami hiba történik az 
JfobenO meghívása után, de az fclose0) meghívása előtt, akkor egy kivétel miatt a use fileO 
függvény az fcloseO végrehajtása nélkül térhet vissza. Ugyanez a probléma kivételkezelést 
nem támogató nyelvek esetében is felléphet. Például a C standard könyvtárának longjimpO 
függvénye ugyanilyen problémát okozhat. Még egy közönséges return utasítás miatt is 
visszatérhet a use file0 az fcloseO végrehajtása nélkül. 


Egy első kísérlet a use file0 hibatűrővé tételére így nézhet ki: 


void use file(const char? fm) 


FILE? f - fopen(fn, "r); 
nyi 
// f használata 
j 
catch (...)( 
Jfelose(D; 
throw; 
j 
Jfelose(D; 
J 


A fájlt használó kód egy try blokkban van, amely minden hibát elkap, bezárja a fájlt, majd 
továbbdobja a kivételt. 
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Ezzel a megoldással az a gond, hogy feleslegesen hosszú, fáradságos és esetleg lassú is 
lehet. Ráadásul minden túl hosszú és fáradságos megoldás nyomában ott járnak a hibák, hi- 
szen a programozók elfáradnak. Szerencsére van jobb megoldás. A megoldandó helyzet 
általános formájában így néz ki: 


void acguireO 


( 
// első erőforrás lekötése 
E sen 


// n-edik erőforrás lekötése 
// erőforrások felhasználása 


// n-edik erőforrás felszabadítása 
Ms 
// első erőforrás felszabadítása 


j 


Általában fontos szempont, hogy az erőforrásokat megszerzésükkel ellentétes sorrendben 
szabadítsuk fel. Ez erőteljesen emlékeztet a konstruktorok által felépített és destruktorok ál- 
tal megsemmisített helyi objektumok viselkedésére. Így aztán az ilyen erőforrás-lefoglalási 
és -felszabadítási problémákat konstruktorokkal és destruktorokkal bíró osztályok objektu- 
mainak használatával kezelhetjük. Például megadhatjuk a File btr osztályt, amely egy 
FILE"-hoz hasonlóan viselkedik: 


class File ptr f 
FILE" p; 
bublic: 
File ptrCconst char? n, const char? a) ( p - foben(n, a); ) 
File ptr(FILEt pp) ( p - pp; ) 
-File ptrO ( fclose(p9; ) 


operator FILE?O ( return p; )? 


Egy File ptr objektumot vagy egy FILE?" mutatóval, vagy az fopen0-hez szükséges paramé- 
terekkel hozhatunk létre; bármelyik esetben élettartama végén a File ptr objektum meg- 
semmisül, destruktora pedig bezárja a fájlt. Programunk mérete így minimálisra csökken: 


void use file(cconst char? fn) 


File ptr Kfn,"rv"); 
// f használata 


J 
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A destruktor attól függetlenül meghívódik, hogy a függvényből , normálisan" vagy kivétel 
kiváltása folytán léptünk-e ki. Így a kivételkezelő eljárás lehetővé teszi, hogy a hibakezelést 
eltávolítsuk a fő algoritmusból. Az így adódó kód egyszerűbb és kevesebb hibát okoz, mint 


hagyományos megfelelője. 


Azt a műveletet, amikor a kivételek kezelésekor a hívási láncban megkeressük a megfelelő 
kezelőt, rendszerint a ,verem visszatekerésének" hívják. Ahogy a vermet , visszatekerik" , 
úgy hívják meg a létrehozott lokális objektumok destruktorait. 


14.4.1. Konstruktorok és destruktorok használata 


Az erőforrások lokális objektumok használatával való kezelését szokás szerint úgy hívják, 
hogy , kezdeti értékadás az erőforrás megszerzésével" (resource acguisition is initialization). 
Ez az általános eljárás a konstruktorok és destruktorok tulajdonságain, valamint a kivétel- 
kezelő rendszerrel való együttműködésükön alapul. 


Egy objektumot addig nem tekintünk létezőnek, amíg konstruktora le nem fut. Destruktora 
csak ebben az esetben fog a verem visszatekerésekor meghívódni. Egy részobjektumokból 
álló objektumot olyan mértékben tekintünk létrehozottnak, amilyen mértékben részobjek- 
tumainak konstruktorai lefutottak, egy tömböt pedig addig az eleméig, amelynek konstruk- 
tora már lefutott. A destruktor a verem visszatekerésekor csak a teljes egészében létrehozott 
elemekre fut le. 

A konstruktor azt próbálja elérni, hogy az objektum teljesen és szabályosan létrejöjjön. Ha 
ez nem érhető el, egy jól megírt konstruktor — amennyire csak lehetséges — olyan állapot- 
ban hagyja a rendszert, mint meghívása előtt volt. Ideális esetben a , naív módon" megírt 
konstruktorok teljesítik ezt és nem hagyják az objektumot valamilyen , félig létrehozott" ál- 
lapotban. Ezt a , kezdeti értékadás az erőforrás megszerzésével" módszernek a tagokra va- 
ló alkalmazásával érhetjük el. 


Vegyünk egy X osztályt, amelynek konstruktora két erőforrást igényel: egy x állományt és 
egy y zárolást. Ezek megszerzése nem biztos, hogy sikerül, és kivételt válthat ki. Az X osz- 
tály konstruktorának semmilyen körülmények között nem szabad úgy visszatérnie, hogy az 
állományt lefoglalta, de a zárat nem. Ezenkívül ezt anélkül kell elérni, hogy a dolog bonyo- 
lultságával a programozónak törődnie kelljen. A megszerzett erőforrások ábrázolására két 
osztályt használunk, a File ptr-t és a Lock ptr-t. Az adott erőforrás megszerzését az azt jelö- 
lő lokális objektum kezdeti értékadása ábrázolja: 
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class X ( 
File ptr aa; 
Lock ptr bb; 
bublic: 
X(const char? x, const char? y) 
: aa(x, "rw"), // 1x! lefoglalása 
bb) // !y" lefoglalása 
íj 
Zé 


Csakúgy mint a lokális objektumos példában, itt is az adott fordító dolga a szükséges nyil- 
vántartások vezetése. A felhasználónak nem kell ezzel törődnie. Például ha az aa létreho- 
zása után, de a bb-é előtt kivétel váltódik ki, akkor az aa destruktorának meghívására sor 
kerül, de a bb-ére nem. 


Ebből következőleg ahol az erőforrások megszerzése ezen egyszerű modell szerint törté- 
nik, ott a konstruktor írójának nem kell kifejezett kivételkezelő kódot írnia. 


Az alkalmi módon kezelt erőforrások között a leggyakoribb a memória: 


class Yf 
int: p; 
void inítO; 
bublic: 
Y(int s) ( p - new intls[; initO; ) 
-YO f delete[ ] p; ) 
M dé 


A fenti módszer használata általános gyakorlat — és a , memória elszivárgásához?" (memory 
leak) vezethet. Ha az initO-ben kivétel keletkezik, a lefoglalt memória nem fog felszabadul- 
ni, mivel az objektum nem jött létre teljesen, így destruktora nem fut le. Íme egy biztonsá- 
gos változat: 


class Z ( 
vectorsint: p; 
void inítO; 
bublic: 
Zdint s) : p(5) € init0; ) 
vs 
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A p által használt memóriát a vector kezeli. Ha az initO kivételt vált ki, a lefoglalt memóri- 
át p (automatikusan meghívott) destruktora fogja felszabadítani. 


14.4.2. Auto ptr 


A standard könyvtár auto ptr sablon osztálya támogatja a , kezdeti értékadás az erőforrás 
megszerzésével" módszert. Egy auto ptr-nek alapvetően egy mutatóval adhatunk kezdőér- 
téket és ugyanúgy hivatkozhatunk a mutatott objektumra, mint egy hagyományos mutató- 
nál. Ezenkívül amikor az auto ptr megsemmisül, az általa mutatott objektum is automatiku- 
san törlődik: 


void Point p1, Point p2, auto ptirSCirclez pc, Shape? pb) // kilépéskor ne felejtsük 
// el törölni pb-t 
( 
auto ptrcShape: p(new Rectangle(p1,p29; // p téglalapra mutat 
auto ptrcShape- pbox(pb); 
b-rotate(45); // az auto ptrcShape: pont úgy használható, mint a Shape" 
VS 
if (in a mess) throw MessO; 
ME sas 
J 


Itt a Rectangle, a pb által mutatott Stape és a pc által mutatott Circle egyaránt törlődni fog, 
akár váltódott ki kivétel, akár nem. 


Ezen tulajdonos szerinti kezelés (vagy destruktív másolás) támogatása céljából az auto ptr- 
eknek a közönséges mutatóktól gyökeresen eltérő másolási módszerük van: egy auto ptr- 
nek egy másikba való másolása után a forrás nem mutat semmire. Minthogy az auto ptr- 
eket a másolás megváltoztatja, konstans (cons0) auto ptr-eket nem lehet másolni. 


Az auto ptr sablont a cmemory? fejállomány deklarálja. Íme egy lehetséges kifejtése: 


templatexclass X- class std::auto ptr f 
template class Y2 struct auto ptr. reff/ ... 7); // segédosztály 
XX? ptr; 

bublic: 
typedef X element type; 


explicit auto ptr(X" p -0) throuO ( ptr-p; ) . /throw0 jelentése "nem vált ki kivételt", 
// lásd §14.6 
-auto ptrO throu0 f delete ptr; ) 
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// figyeljük meg: másolás és értékadás nem konstans paraméterekkel 


auto ptr(auto ptrk a) throwO; // másol, majd a.ptr-O 
templatexclass Y2 auto ptr(auto ptrcY2£ a) throwO; // másol, majd a.ptr-O 
auto pirk operator—(auto ptrk a) throwO); // másol, majd a.ptrz-O 


templatesclass Y2 auto pirk operator-(auto ptircY:k a) throwO; // másol, majd a.ptr-O 


X£ operator?) const throuO f( return ?ptr; ) 

X" operator-20 const throwuO f return ptr; ) 

X" get0 const throu0 f return ptr; ) // mutató kinyerése 
X" release0 throwuO [( X" t - ptr; btr-O; return t; ) // tulajdonosváltás 
void reset(X" p -0) throu0 f if (p!-ptr) f delete ptr; ptr-b; ) ) 


auto ptr(auto ptr. refZX2) throwO; // másolás auto ptr. ref-ből 
templatezclass Y: operator auto ptr. refgY50 throwO); // másolás auto. ptr. ref-be 
templatexclass Y: operator auto ptrcY50 throwO; // destruktív másolás auto ptr-ből 


Az auto ptr. ref célja, hogy megvalósítsa a közönséges auto ptr számára a destruktív má- 
solást, ugyanakkor megakadályozza egy konstans auto btr másolását. Ha egy D"-ot B"-gá 
lehet alakítani, akkor a sablonkonstruktor és a sablon-értékadás (meghatározott módon 
vagy automatikusan) egy auto btrCD:-t auto ptrSB--vé tud alakítani: 


void (Circle? pc) 

( 
auto ptrxCirclez p2 - pc; // most p2 felel a törlésért 
auto ptr£Circlez p3 - p2; // most p3 felel a törlésért (p2 már nem) 
b2-m - 7; // programozói hiba: b2.get0--0O 
Shape? ps - p3.getO; // mutató kinyerése auto ptr-ból 
auto ptrcShape? aps - p3; // tulajdonosváltás és típuskonverziő 
auto ptrxCircle: p4 - pc; // programozói hiba: most pá is felel a 


// törlésért 


Az nem meghatározott, mi történik, ha több auto btris mutat egy objektumra, de az a leg- 
valószínűbb, hogy az objektum kétszer törlődik — ami hiba. 


Jegyezzük meg, hogy az auto pbtr destruktív másolási módszere miatt nem teljesíti a szab- 
ványos tárolók elemeire vagy a sortO-hoz hasonló szabványos eljárásokra vonatkozó köve- 
telményeket: 


vector£ auto ptrcShape: 28 vu;  // veszélyes: auto ptr használata tárolóban 
TES 
sort(v.beginO, v.endO 9; // Ezt ne tegyük: a rendezéstől v sérülhet 
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Világos, hogy az auto ptr nem egy általános , okos" vagy , intelligens" mutató (smart poin- 
ter). De amire tervezték — az automatikus mutatók kivételbiztos kezelésére — arra lényeges 
, költség" nélkül megfelel. 


14.4.3. Figyelmeztetés 


Nem minden programnak kell mindenfajta hibával szemben immunisnak lennie és nem 
minden erőforrás annyira létfontosságú, hogy a védelme megérje a , kezdeti értékadás az 
erőforrás megszerzésével" módszernek, az auto ptr-nek, illetve a catchC ..) alkalmazásának 
fáradságát. Például sok, egyszerűen a bemenetet olvasó és azzal le is futó programnál a sú- 
lyosabb futási idejű hibákat úgy is kezelhetjük, hogy egy alkalmas hibaüzenet kiadása után 
a programot leállítjuk. Ezzel a rendszerre bízzuk a program által lefoglalt összes erőforrás 
felszabadítását, így a felhasználó újrafuttathatja a programot egy jobb bemenettel. Az itt le- 
írt módszer olyan alkalmazások számára hasznos, amelyeknél a hibák ilyesféle egyszerűsí- 
tett kezelése elfogadhatatlan. Egy könyvtár tervezője például általában nem élhet feltevé- 
sekkel a könyvtárat használó program hibatűrési követelményeit illetően, így aztán el kell 
kerülnie minden feltétel nélküli futási idejű hibát és minden erőforrást fel kell szabadítania, 
mielőtt egy könyvtári függvény visszatér. A , kezdeti értékadás az erőforrás megszerzésével" 
módszer a kivételeknek a hibák jelzésére való felhasználásával együtt sok ilyen könyvtár 
számára megfelelő. 


14.4.4. A kivételek és a new operátor 


Vegyük a következőt: 


void (Arenak a, X" buffer) 
( 

X"p1 - new X; 

X7 p2 - new XI10/; 


X" p3 - new(buffje10)) X; // X átmeneti tárba helyezése (nem 
// szükséges felszabadítás) 
X7 p4 - new(bujfje11D XI10]; 


X" p5 - neu(a) X; // tárfoglalás az "a! Arena-tól (a-t kell 
// felszabadítani) 
X" p6 - neu(a) XI10]; 
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Mi történik, ha X konstruktora kivételt vált ki? Felszabadul-e a newO operátor által lefoglalt 
memória? Közönséges esetben a válasz igen, így bJ1 és p2 kezdeti értékadása nem okoz me- 
mória-elszivárgást. 


Ha az elhelyező utasítást (placement syntax, §10.4.11) használjuk, a válasz nem ennyire 
egyszerű. Az elhelyező utasítás némely felhasználása lefoglal némi memóriát, amit aztán fel 
kellene szabadítani, de némelyik nem. Ezenkívül az elhelyező utasítás alkalmazásának 
éppen a memória nem szabványos lefoglalása a lényege, így aztán jellemzően nem szabvá- 
nyos módon is kell felszabadítani azt. Következésképpen a továbbiak a felhasznált memó- 
riafoglalótól (allokátortól) függnek. Ha egy Z::operator newO memóriafoglaló szerepelt, ak- 
kor a rendszer meghívja a Z::operator delete -et, feltéve, hogy van ilyen; más módon nem 
próbál felszabadítást végezni. A tömbök kezelése ezzel azonos módon történik (§15.6.19. Ez 
az eljárás helyesen kezeli a standard könyvtárbeli elhelyező new operátort (410.4.11), csak- 
úgy, mint minden olyan esetet, amikor a programozó összeillő lefoglaló és felszabadító 
függvénypárt írt. 


14.4.5. Az erőforrások kimerülése 


Visszatérő programozási dilemma, hogy mi történjék, ha nem sikerül egy erőforrás lefogla- 
lási kísérlete, például mert korábban meggondolatlanul nyitogattunk fájlokat (az fobenO- 
nel) és foglaltunk le memóriát a szabad tárban (a new operátorral), anélkül, hogy törődtünk 
volna vele, mi van, ha nincs meg a fájl vagy hogy kifogytunk-e a szabad tárból. Ilyen prob- 
lémával szembesülve a programozók kétféle megoldást szoktak alkalmazni: 


1. Újrakezdés: kérjünk segítséget valamelyik hívó függvénytől és folytassuk a prog- 
ram futását. 
2. Befejezés: hagyjuk abba a számítást és térjünk vissza a hívóhoz. 


Az első esetben a hívónak fel kell készülnie arra, hogy segítséget adjon egy ismeretlen kód- 
részletnek annak erőforrás-lefoglaló problémájában. A második esetben a hívónak arra kell 
felkészülnie, hogy kezelje az erőforrás-lefoglalás sikertelenségéből adódó problémát. A má- 
sodik eset a legtöbbször sokkal egyszerűbb és a rendszer elvonatkoztatási szintjeinek jobb 
szétválasztását teszi lehetővé. Jegyezzük meg, hogy a , befejezés" választásakor nem a prog- 
ram futása fejeződik be, hanem csak az adott számítás. A , befejezés" (termination) azon el- 
járás hagyományos neve, amely egy , sikertelen" számításból a hívó által adott hibakezelő- 
be tér vissza (ami aztán újra megpróbálhatja a számítást elvégeztetni), ahelyett, hogy 
megpróbálná maga orvosolni a helyzetet és a hiba felléptének helyéről folytatni a számítást. 
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A C44-ban az újrakezdő modellt a függvényhívási eljárás, a befejező modellt a kivételkeze- 
lő eljárás támogatja. Mindkettőt szemlélteti a standard könyvtárbeli newO operátor egy egy- 
szerű megvalósítása és felhasználása: 


void? operator neu(size t size) 


( 
Jor GD ( 
if (void? p - malloc(size)) return p; // megpróbálunk memóriát találni 
if (C new handler -—- 0) throw bad allocO; // nincs kezelő: feladjuk 
. new handlerO; // segítséget kérünk 
J 
J 


Itt a C standard könyvtárának mallocO függvényét használtam a szabad memóriahely tény- 
leges megkeresésére; az operator new() más változatai más módokat választhatnak. Ha si- 
került memóriát találni, a new operátor visszaadhatja az arra hivatkozó mutatót; ha nem, 
a newO meghívjaa new handler-t. Ha az talál a mallocO számára lefoglalható memóriát, 
akkor minden rendben. Ha nem, akkor a kezelő nem térhet vissza a new operátorba vég- 
telen ciklus okozása nélkül. A new handler ekkor kivételt válthat ki, ilyen módon valame- 
lyik hívóra hagyva a helyzet tisztázását: 


void my new handlerO 


( 
int no of bytes found - find some memoryO; 
if (no of bytes found £ min allocation) throw bad allocO;  // feladjuk 


j 


Valahol lennie kell egy try blokknak is, a megfelelő kivételkezelővel: 


try( 
// ... 
) 


catch (bad alloc) ( 
// valahogy reagálunk a memória kifogyására 


J 


A newO operátor ezen változatában használt new handler egy, a szabványos 
set new handlerO függvény által fenntartott függvénymutató. Ha saját my new handlerO- 
ünket szeretnénk new handler-ként használni, ezt írhatjuk: 


set new handler(r(kmy new handler); 
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Ha el akarjuk kapni a bad alloc kivételt is, ezt írhatjuk: 


void JO 
( 
voidCtoldnh)O - set new handler(kmy new handler); 
try ( 
HANS 
) 
catch (bad alloc) f 
Je 
) 
catch (...) ( 
set new handlerColdnh); // kezelő újbóli beállítása 
throw; // továbbdobás 
J 
set new handlerColdnh); // kezelő újbóli beállítása 


J 
Még jobb, ha a catchC...) kezelőt a , kezdeti értékadás az erőforrás megszerzésével" mód- 
szernek (§14.4)a new handler-re való alkalmazásával elkerüljük (414.12[1D. 


A new handler alkalmazásával a hiba észlelésének helyétől semmiféle további információ 
nem jut el a segédfüggvényig. Könnyű több információt közvetíteni, ám minél több jut el 
belőle egy futási idejű hiba észlelésének helyétől a kijavítást segítő helyig, a két kód annál 
inkább függ egymástól. Ebből adódóan az egyik kódrészleten csak a másikat értve és eset- 
leg azt módosítva lehet változtatni. A különböző helyen levő programrészek elszigetelésé- 
re jó módszer, ha az ilyen függéseket a legkisebb mértékre szorítjuk vissza. A kivételkeze- 
lő eljárás jobban támogatja az elszigetelést, mint a hívó által biztosított segédfüggvények 
meghívása. 


Általában célszerű az erőforrások megszerzését rétegekbe, elvonatkoztatási szintekbe szer- 
vezni, és elkerülni, hogy egy réteg a hívó réteg segítségére szoruljon. Nagyobb rendszerek 
esetében a tapasztalat azt mutatja, hogy a sikeres rendszerek ezt az utat követik. 


A kivételek kiváltásához szükség van egy ,eldobandó" objektumra. Az egyes C-t-- 
változatoktól elvárjuk, hogy a memória elfogyásakor is maradjon annyi tartalék, amennyi 
egy bad alloc kiváltásához kell, de lehetséges, hogy valamilyen más kivétel dobása a me- 
mória elfogyásához vezet. 
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14.4.6. Kivételek konstruktorokban 


A kivételek adnak megoldást arra a problémára, hogyan jelentsünk hibát egy konstruktorból. 
Minthogy a konstruktorok nem adnak vissza külön visszatérési értéket, amelyet a hívó meg- 
vizsgálhatna, a hagyományos (azaz kivételeket nem alkalmazó) lehetőségek a következők: 


1. Adjunk vissza egy hibás állapotú objektumot, megbízva a hívóban, hogy az majd 
ellenőrzi az állapotot. 

2. Állítsunk be egy nem lokális változót (például az errno-t), hogy jelezze a létreho- 
zás sikertelenségét, és bízzunk a felhasználóban, hogy ellenőrzi a változót. 

3. Ne végezzünk kezdeti értékadást a konstruktorban és bízzunk meg a felhaszná- 
lóban, hogy az első használat előtt elvégzi azt. 

4. Jelöljük meg az objektumot , kezdőérték nélküli"-ként, és végezze az első meghí- 
vott tagfüggvény a kezdeti értékadást. Ez a függvény jelenti majd a hibát, ha 
a kezdeti értékadás nem sikerült. 


A kivételkezelés lehetőséget ad arra, hogy a létrehozás sikertelenségére vonatkozó infor- 
mációt a konstruktorból átadjuk. Egy egyszerű Vector osztály például így védekezhet a túl- 
zott igények ellen: 


class Vector (f 
bublic: 
class Size ( 3); 


enum f max - 32000 ); 


Vector(int sz) 


( 
if (szS0o I I maxcsz) throw SizeO; 
KZT 

J 

VBEN 


j; 
A Vector-okat létrehozó kód most elkaphatja a Vector::Size hibákat, és megpróbálhatunk 
valami értelmeset kezdeni velük: 


Vector? f(int i) 
( 
try ( 
Vector?" p - new Vector(i); 
VAY 
return p; 
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catch(Vector::Size) ( 
// mérethiba kezelése 


J 


j 


Mint mindig, maga a hibakezelő az alapvető hibakezelő és -helyreállító módszerek szoká- 
sos készletét alkalmazhatja. Valahányszor a hívó egy kivételt kap, megváltozik annak értel- 
mezése, hogy mi volt a hiba. Ha a kivétellel együtt a megfelelő információ is továbbítódik, 
a probléma kezeléséhez rendelkezésre álló ismeretek halmaza akár bővülhet is. Más szó- 
val, a hibakezelő módszerek alapvető célja az, hogy a hiba felfedezésének eredeti helyéről 
olyan helyre jutassunk el információt, ahol elegendő ismeret áll rendelkezésre a hiba kö- 
vetkezményeinek elhárításához, és ezt ráadásul megbízhatóan és kényelmesen tegyük. 


A , kezdeti értékadás az erőforrás megszerzésével" eljárás az egynél több erőforrást igény- 
be vevő konstruktorok kezelésének legbiztosabb és legelegánsabb módja (414.4). Ez lénye- 
gében a sok erőforrás kezelésének problémáját az egy erőforrást kezelő egyszerűbb eljárás 
ismételt alkalmazására vezeti vissza. 


14.4.6.1. Kivételek és a tagok kezdeti értékadása 


Mi történik, ha egy tag kezdeti értékadása közvetlenül vagy közvetve kivételt vált ki? Alap- 
értelmezés szerint a kivételt az a hívó függvény kapja meg, amelyik a tag osztályának 
konstruktorának meghívta, de maga a konstruktor is elkaphatja azt, ha a teljes függvénytör- 


Zset a tag kezdőérték-listájával együtt egy íry blokkba zárjuk: 


class X ( 
Vector v; 
VSE 

bublic: 
X(int9; 
Mae 


J; 


X::X(int 5) 

íy 
:V(5) // v kezdőértéke s 

( 
EE 

j 

catch (Vector::Size) ( // a v által kiváltott kivételt itt kapjuk el 
Ma 


J 
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14.4.6.2. Kivételek és másolás 


Más konstruktorokhoz hasonlóan a másoló konstruktor is jelezheti a hibás futást kivétel ki- 
váltásával. Ebben az esetben az objektum nem jön létre. A vector másoló konstruktora pél- 
dául memóriát foglal le és átmásolja az elemi objektumokat (16,3,4,, E.3.2.), ami kivételt 
válthat ki. A kivétel kiváltása előtt a másoló konstruktor fel kell szabadítsa a lefoglalt erő- 
forrásokat. Az E.2. és E.3. függelékekben részletesen tárgyaljuk a kivételkezelés és a táro- 
lók erőforrás-gazdálkodásának kapcsolatait. 


A másoló értékadó operátor ugyanígy lefoglalhat erőforrásokat és kiválthat kivételt. Mielőtt 
ez utóbbit tenné, az értékadásnak biztosítania kell, hogy mindkét operandusát azonos álla- 


potban hagyja. Más esetben megszegjük a standard könyvtárbeli előírásokat, melynek kö- 
vetkezménye nem meghatározott viselkedés lehet. 


14.4.7. Kivételek destruktorokban 
A kivételkezelő eljárás szemszögéből nézve egy destruktort kétféleképpen lehet meghívni: 


1. Normál (szabályos) meghívás: a hatókörből való szabályos kilépéskor ((410.4.3) 
vagy egy delete hívás folytán (410.4.5) stb. 

2. Kivételkezelés közbeni meghívás: a verem visszatekerése közben (414.4) a kivétel- 
kezelő eljárás elhagy egy blokkot, amely destruktorral bíró objektumot tartalmaz. 


Az utóbbi esetben a kivétel nem léphet ki a destruktorból. Ha megteszi, az a kivételkezelő 
eljárás hibájának számít, és meghívódik az std::terminateO (§14.7). Végülis a kivételkezelő 
eljárásnak és a destruktornak általában nincs módja eldönteni, hogy elfogadható-e az egyik 
kivételnek a másik kedvéért való elhanyagolása. 


Ha a destruktor olyan függvényt hív meg, amely kivételt válthat ki, akkor ez ellen védekezhet: 


X::-XO 


try ( 
JO;  — / kivételt válthat ki 


J 
catch (...) ( 
// valamit csinálunk 


J 
A standard könyvtárbeli uncaught exceptionÖ függvény true-val tér vissza, ha van olyan 
, eldobott" kivétel, amelyet még nem kaptak el. Ez lehetővé teszi a destruktor attól függő 
programozását, hogy az objektum szabályos vagy a verem visszatekerése közbeni megsem- 
misítéséről van-e szó. 
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14.5. Kivételek, amelyek nem hibák 


Ha egy kivételre számítunk és elkapjuk és így annak nincs a program működésére nézve 
rossz következménye, akkor miért lenne hiba? Csak mert a programozó a kivételre mint hi- 
bára és a kivételkezelő eljárásokra pedig mint hibakezelő eszközökre gondol? Nos, a kivé- 
teleket úgy is tekinthetjük, mintha vezérlőszerkezetek lennének: 


void (Oueuecx-k ag) 
( 
ny t 
Jor GJ f 
X m - g.getO; // "Empty" kivételt vált ki, ha a sor üres 
Ma 


J 


) 

J 

catch (DueuexX2::Empty) ( 
return; 


J 


j 
Ez egészen jónak tűnik, így ebben az esetben tényleg nem teljesen világos, mi számít hibá- 
nak és mi nem. 


A kivételkezelés kevésbé rendezett eljárás, mint az if-hez vagy a for-hoz hasonló helyi ve- 
zérlési szerkezetek és azoknál gyakran kevésbé hatékony is, ha a kivételre ténylegesen sor 
kerül. Ezért kivételeket csak ott használjunk, ahol a hagyományosabb vezérlési szerkezetek 
nem elegánsak vagy nem használhatóak. A standard könyvtár például tartalmaz egy tetsző- 
leges elemekből álló guewe-t (sor) is, kivételek alkalmazása nélkül (417.3.29. 


A keresőfüggvényeknél -— különösen a rekurzív hívásokat nagymértékben alkalmazó függ- 
vényeknél (például egy fában kereső függvénynélb - jó ötlet befejezésként kivételt 
alkalmazni: 


void fnd(Iree?" p, const stringét 5) 

( 
if (s —— p-str) throw p; // megtalálta s-t 
if (p-olef) fad(p-leji,5); 
if (pcrigh)) fnd(b--right, 5); 


J 


Tree? find(Iree? p, const stringé s) 


( 
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nyi 
Jfmnd(p,5); 


j 
catch (Tree? ag) ( // g-2str-zs 
return g; 


J 


return 0; 


Ugyanakkor a kivételek ilyen használata könnyen túlzásba vihető és áttekinthetetlen kód- 
hoz vezethet. Ha ésszerű, ragaszkodjunk ,a kivételkezelés hibakezelés" elvhez. Ekkor 
a kód világosan két részre különül: közönséges és hibakezelő kódra. Ez érthetőbbé teszi 
a kódot. Sajnos a , való" világ nem ilyen tiszta, a program szerkezete pedig ezt (bizonyos fo- 
kig kívánatos módon) tükrözni fogja. 


A hibakezelés lényegénél fogva nehéz. Becsüljünk meg mindent, ami segít egy világos mo- 
dellt kialakítani arról, mi számít hibának és hogyan kezeljük. 


14.6. Kivételek specifikációja 


A kivétel kiváltása vagy elkapása befolyásolja a függvénynek más függvényekhez való vi- 
szonyát. Ezért érdemes lehet a függvény deklarációjával együtt megadni azon kivételeket 
is, amelyeket a függvény kiválthat. 


void (int a) throw (Xx2, x3); 


Ha egy függvény megadja, milyen kivételek léphetnek fel végrehajtása közben, akkor ez- 
zel valójában garanciát nyújt a használóinak. Ha a függvény futása közben valamit olyasmit 
próbál tenni, ami ezt a garanciát érvénytelenné tenné, akkor ez a kísérlet az 
std::unexpectedO hívássá fog átalakulni. Az unexpectedŐ alapértelmezett jelentése 
std::terminateO), ami szokványos esetben meghívja az abortO-ot. (Részletesen lásd 
a §9.4.1.1 pontban.) Valójában a 


void JO throw (x2, x3) 


// törzs 
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egyenértékű a következővel: 


void JO 
íry 
( 


// törzs 


j 


catch (x2) ( throu; ) // továbbdobás 
catch (x3) f( throw; ) // továbbdobás 
catch (...) ( 


std::unexpectedO; — // az unexpectedO nem fog visszatérni 


JA 


Ennek legfontosabb előnye, hogy a függvény deklarációja a hívók által elérhető felület ré- 
sze. A függvénydefiníciók viszont nem általánosan elérhetőek. Ha hozzá is férünk az összes 
könyvtár forrásához, határozottan nem szeretünk sűrűn beléjük nézegetni, ráadásul a meg- 
kivétel-specifikációkkal (exception specification) ellátott függvénydeklarációk sokkal rövi- 
debbek és világosabbak, mint az egyenértékű kézzel írott változat. 


A kivétel-specifikációk nélküli függvényekről azt kell feltételeznünk, hogy bármilyen kivé- 
telt kiválthatnak: 


int fO; // bármilyen kivételt kiválthat 
A kivételt ki nem váltó függvényeket üres listával adhatjuk meg: 
int g0 throw O;  // nem vált ki kivételt 


Azt gondolhatnánk, az lenne a jó alapértelmezés, hogy a függvény nem váltana ki kivételt. 
Ekkor azonban alapvetően minden függvény részére szükséges lenne kivételeket meghatá- 
rozni, emiatt pedig sokszor kellene újrafordítani és meg is akadályozná a más nyelveken írt 
programokkal való együttműködést. Ez aztán arra ösztönözné a programozókat, hogy , ak- 
názzák alá" a kivételkezelő rendszert és hogy hibás kódot írjanak a kivételek elfojtására, ez 
pedig az aknamunkát észre nem vevőknek hamis biztonságérzetet adna. 


14.6.1. A kivételek ellenőrzése 


Egy felületnek fordítási időben nem lehet minden megsértési kísérletét ellenőrizni, de azért 
fordításkor sok ellenőrzés történik. A specifikált (tehát , engedélyezett") kivételeket a fordí- 
tó úgy értelmezi, hogy a függvény azok mindegyikét ki fogja váltani. A kivétel-specifikációk 
fordítási idejű ellenőrzésének szabályai a könnyen felderíthető hibákat tiltják. 


14. Kivételkezelés 495 


Ha egy függvény valamely deklarációja megad kivételeket is, akkor mindegyik deklaráció- 
jának (és definiciójának is) tartalmaznia kell pontosan ugyanazokat a kivételeket: 


int fO throw (std::bad alloc); 


int JO // hiba: a kivétel-meghatározás hiányzik 
( 

119 s 
j 


Fontos szempont, hogy a kivételek fordítási egységek határain átnyúló ellenőrzése nem kö- 
telező. Természetesen az adott nyelvi változat ellenőrizhet így, de a nagyobb rendszerek leg- 
többje számára fontos, hogy ez ne történjen meg, vagy ha mégis, csak akkor jelezzen végze- 
tes hibát, ha a kivétel-specifikációk megsértését nem lehet majd futási időben elkapni. 


A lényeg az, hogy új kivétellel való bővítés ne kényszerítse ki a kapcsolódó kivétel- 
specifikációk kijavítását és az esetleg érintett összes kód újrafordítását. A rendszer így egy 
félig felújított állapotban tovább működhet és a váratlan kivételek dinamikus (futási időbe- 
li) észlelésére hagyatkozhat, ami alapvető az olyan nagy rendszereknél, ahol a nagyobb 
frissítések költségesek és nincs is meg az összes forrás. 


Egy virtuális függvényt csak olyan függvénnyel lehet felülírni, amely legalább annyira szi- 
gorúan határozza meg a kivételeket, mint maga az eredeti függvény: 


class Bf 

public: 
virtual void fO; // bármit kiválthat 
virtual void g0 throu(x, Y); 
virtual void hO throw(x); 


3; 
class D : public Bf 
bublic: 
void fO throu(X); // rendben 
void g0 throu(xX); // rendben: D::g0 szigorúbb, mint B::g0 
void hO throu(X, Y); // hiba: D::10 megengedőbb, mint B::hO 
3; 


Ezt a szabályt a józan ész diktálja. Ha egy származtatott osztály olyan kivételt váltana ki, 
amit az eredeti függvény nem adott meg lehetségesként, annak elkapását nem várhatnánk 
el a hívótól. Másrészt egy felülíró függvény, amely kevesebb kivételt vált ki, betartja a felül- 
írt függvény kivétel-specifikációjában felállított szabályokat. 
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Ugyanígy egy, a kivételeket szigorúbban meghatározó függvényt hozzárendelhetünk egy 
megengedőbb függvénymutatóhoz, de fordítva nem: 


void fO throu(x); 
void Cpf0O throu(x,Y) - £f; // rendben 
void Cpf290 throuO - £f; // hiba: fO megengedőbb, mint pf2 


Kivétel-specifikáció nélküli függvényre hivatkozó mutatót kivételeket meghatározó függ- 
vénymutatóhoz különösképpen nem rendelhetünk: 


void gO;  // bármit kiválthat 


void Cpf3)O throu(X) - £g; // hiba: g0 megengedőbb, mint pf3 


A kivétel-specifikáció nem része a függvény típusának, a typedef-ek pedig nem is tartalmaz- 
hatnak ilyet: 


typedef void (GPF)O throu(X); // hiba 


14.6.2. Váratlan kivételek 

Ha a kivételek köre specifikált, az ott nem szereplő kivételek az unexpectedO meghívását 

válthatják ki. Az ilyen hívások a tesztelésen kívül általában nem kívánatosak. A kivételek 

gondos csoportosításával és a felületek megfelelő meghatározásával viszont elkerülhetők, 

de az unexbectedŐ hívásokat is el lehet fogni és ártalmatlanná tenni. 

Egy megfelelően kidolgozott Yalrendszer gyakran az Yerr osztályból származtatja a kivételeit: 
class Some Yerr : public Yerr ( /§ ... "/ 3; 


A fenti esetében a 


void fO throw (Xerr, Yerr, exception); 


minden NYerr-t továbbítani fog a hívójának. Így tehát /0 a Some Yerr osztályú hibát is továb- 
bítani fogja és /0-ben semmilyen fYerr nem fog unexpectedŐ hívást kiváltani. 


A standard könyvtár által kiváltott összes kivétel az exception osztály (§14.10) leszármazottja. 
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14.6.3. Kivételek leképezése 


A programot leállítani kezeletlen kivétel fellépése esetén néha túl könyörtelen eljárás. 
Ilyenkor az unexpectedO viselkedését kell elfogadhatóbbá tenni. 


Ennek az a legegyszerűbb módja, hogy a standard könyvtárbeli szd::bad exception-t fel- 
vesszük a specifikált kivételek közé. Ekkor az unexpectedŐ egyszerűen egy bad exception- 
t fog kiváltani egy kezelőfüggvény meghívása helyett: 


class X f 3; 
class Y ( 3; 


void fO throu(X, std::bad exception) 


í 
ÜRES 
throw YO; // bad exception-t vált ki 


A kivételkezelő ekkor elkapja az elfogadhatatlan Y kivételt és bad exception típusút vált ki 
helyette. A bad exception-nel semmi baj, a terminate0-nél kevésbé drasztikus — de azért 
így is meglehetősen durva beavatkozás, ráadásul az információ, hogy milyen kivétel okoz- 
ta a problémát, elvész. 


14.6.3.1. Kivételek felhasználói leképezése 


Vegyünk egy g0 függvényt, amely nem hálózati környezethez készült. Tételezzük fel, hogy 
g0 csak a saját ,Y alrendszerével" kapcsolatos kivételek kiváltását engedélyezi. Tegyük fel, 
hogy g0-t hálózati környezetben kell meghívnunk. 


void gO throuw(Yerr); 


Természetesen g0 nem fog tudni semmit a hálózati kivételekről és az unexbectedO-et fog- 
ja meghívni, ha ilyennel találkozik. A g0 hálózati környezetben való használatához olyan 
kódra van szükségünk, amely hálózati kivételeket kezel, vagy át kell írnunk g0-t. Tegyük 
fel, hogy az újraírás nem lehetséges vagy nem kívánatos. Ekkor a problémát az 
unexpectedO jelentésének felülbírálásával oldhatjuk meg. 


A memória elfogyásáta new handler kezeli, amelyet a set new handlerőO állít be. Ugyan- 
így a váratlan kivételre adott választ egy  unexpected handler határozza meg, amelyet az 
Zexception: fejállományban megadott sid::set unexpectedŐO állít be: 
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typedef void unexpected handler); 
unexpected handler set unexpected(unexpected handler); 


A váratlan kivételek megfelelő kezeléséhez létre kell hoznunk egy osztályt, hogy a , kezde- 
ti értékadás az erőforrás megszerzésével" módszert használhassuk az unexpectedO függvé- 
nyekben: 


class STC ( // tárol és visszaállít 
unexpected handler old; 
bublic: 


S7TC(unexpected handdler f) f old - set unexpected(f9; ) 
-STCO f set unexpected(old); ) 


Ezután definiálunk egy függvényt az unexpectedŐ erre az esetre kívánt jelentésével: 
class Yunexpected : public Yerr f ); 


void throwYO throu(Yunexpected) ( throw YunexpectedO); ) 


A throwYO-t unexpectedO-ként használva bármilyen kivételből Yunexpected lesz. 


Végül elkészíthetjük g0-nek egy hálózati környezetben alkalmazható változatát: 


void networked g0 throu(Yerr) 


( 
STC xx(kthrowY); — // az unexpectedO most Yunexpected-et vált ki 


20; 


j 
Mivel az Yunexpected az Yerr-ből származik, a kivétel-specifikáció nem sérül. Ha 
a throwYO olyan kivételt váltott volna ki, amit a specifikáció nem engedélyez, akkor 
a terminate0 hajtódott volna végre. 


Azáltal, hogy mentettük és visszaállítottuk az unexpected handler-t, több alrendszer szá- 
mára tettük lehetővé — egymásra való hatás nélkül — a váratlan kivételek kezelését. A várat- 
lan kivételek engedélyezetté alakításának e módszere alapvetően a rendszer által 
a bad exception-nal nyújtott szolgáltatás rugalmasabb változata. 
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14.6.3.2. Kivételek típusának visszaállítása 

A váratlan kivételek Yunexpected-dé alakítása lehetővé tenné a networked g0 felhasználó- 
jának, hogy megtudja: egy váratlan kivételt képeztünk le az Yunexpected-re. Azt azonban 
nem fogja tudni, hogy melyik kivétel leképezése történt meg. Egy egyszerű eljárással lehe- 
tővé tehetjük ennek megjegyzését és továbbítását. Például így tudnánk információt gyűjte- 
ni a Network. exception-ökről: 


class Yunexpected : public Yerr f 

bublic: 
Network exception? pe; 
Yunexpected(Network exception? p) :pe(p:p-2cloneO:0) 1 ) 
-YunexpectedO f delete p; ) 


H 
void throwYO throw(Yunexpected) 
f 
try ( 
throw; // A továbbdobott kivételt azonnal el kell kapni! 
j 
catch(Network exceptionk p) ( 
throw Yunexpected(kp); // leképezett kivétel kiváltása 
j 
catch(C...) ( 
throw Yunexpected(0); 
j 
J 


A kivételek továbbdobása és elkapása lehetővé teszi, hogy azon típusok összes kivételét 
kezeljük, amelyeket meg tudunk nevezni. A throwYO függvényt az unexpectedO hívja meg, 
azt pedig elvileg egy catchC...) kezelő. Így tehát biztosan van továbbdobható kivétel. Egy 
unexpectedŐ függvény nem tekinthet el a hibától és nem térhet vissza. Ha megpróbál így 
tenni, az unexpectedŐO maga fog bad expection-t kiváltani (§14.6.3). A clone0 függvényt 
arra használjuk, hogy a kivétel egy másolata számára helyet foglaljon a szabad memóriá- 
ban. Ez a másolat túléli a verem , visszatekerését" . 


14.7. El nem kapott kivételek 


Ha egy kivételt nem kapnak el, akkor az std::terminate0 meghívására kerül sor. 
A terminate0 fog meghívódni akkor is, ha a kivételkezelő eljárás a vermet sérültnek talál- 
ja, vagy ha egy, a verem visszatekerése során meghívott destruktor kivétel kiváltásával pró- 
bál véget érni. 
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A váratlan kivételeket az unexpected handler kezeli, amelyet az std::set unexpectedO ál- 
lít be. Ehhez hasonlóan, az el nem kapott kivételek kezelésétaz uncaught handler vég- 
zi, amelyet az Cexception: fejállományban megadott std::set uncaughtO állít be: 


typedef voidC terminate handler)O; 
terminate handler set terminate(terminate handler); 


A visszatérési érték a set terminateO-nek előzőleg adott függvény. 


A terminate0 meghívásának oka, hogy időnként a kivételkezeléssel fel kell hagyni kevés- 
bé kifinomult hibakezelési módszerek javára. A terminate0-et például használhatjuk arra, 
hogy megszakítsunk egy folyamatot vagy esetleg újraindítsunk egy rendszert (új kezdeti ér- 
tékadással). A terminate0 meghívása drasztikus intézkedés: akkor kell használni, amikor 
a kivételkezelő eljárás által megvalósított hibakezelő stratégia csődöt mondott és ideje a hi- 
batűrés más szintjére áttérni. 


A terminate0 alapértelmezés szerint az abortO-ot hívja meg (§9.4.1.19. Ez az alapértelme- 
zés a legtöbb felhasználó számára megfelelő választás, különösen a program hibakeresése 
(debugging) alatt. 


Az uncaught handler függvényekről a rendszer feltételezi, hogy nem fognak visszatérni 
a hívójukhoz. Ha az adott függvény megpróbálja, a terminate0 meg fogja hívni az abortO-ot. 


Jegyezzük meg, hogy az abortO a programból való nem szabályos kilépést jelent. Az exit 
függvény visszatérési értékével jelezhetjük a rendszernek, hogy a programból szabályosan 
vagy nem szabályosan léptünk-e ki (49.4.1.1. 


Az adott nyelvi változat határozza meg, hogy a program futásának el nem kapott kivétel mi- 
atti befejeződésénél a destruktorok meghívódnak-e. Bizonyos rendszereknél alapvető, 
hogy a destruktorok ne hívódjanak meg, hogy a program futtatását folytatni lehessen a hi- 
bakeresőből. Más rendszerek számára felépítésükből adódóan szinte lehetetlen nem meg- 


hívni a destruktorokat a kivétel kezelőjének keresésekor. 


Ha biztosítani akarjuk a rendrakást egy el nem kapott kivétel esetében, a mainO függvény- 
ben a ténylegesen elkapni kívánt kivételek mellé írhatunk egy minden kivételt elkapó ke- 
zelőt is (414.3.29: 


int mainŐ 
try ( 
lesza 


j 
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catch (std::range error) 


( 


cerr ££ "Tartományhiba: már megintNm"; 


catch (std::bad alloc) 


) cerr 22 "A new kifogyott a memóriából Mn"; 
J 
catch (...) ( 
Ül séta 
J 


Ez a globális változók konstruktorai és destruktorai által kiváltottak kivételével minden ki- 
vételt elkap. A globális változók kezdeti értékadása alatt fellépő kivételeket nem lehet el- 
kapni. Egy nem lokális statikus objektum kezdeti értékadása közbeni tArow esetében csak 
a set unexpectedO (§14.6.2) segítségével kaphatjuk meg a vezérlést, ami újabb ok arra, 


hogy lehetőség szerint kerüljük a globális változókat. 


A kivételek kiváltásánál a kivétel fellépésének pontos helye általában nem ismert, vagyis 
kevesebb információt kapunk, mint amit egy hibakereső (debugger) tudhat a program ál- 
lapotáról. Ezért bizonyos C-t- fejlesztőkörnyezetek, programok vagy fejlesztők számára 
előnyösebb lehet nem elkapni azokat a kivételeket, amelyek következményeit a program- 
ban nem küszöböljük ki. 


14.8. A kivételek és a hatékonyság 


Elvileg lehetséges a kivételkezelést úgy megtervezni, hogy az ne járjon a futási idő növeke- 
désével, ha nem kerül sor kivétel kiváltására. Ráadásul ezt úgy is meg lehet tenni, hogy egy 
kivétel kiváltása ne legyen különösebben költséges egy függvényhíváshoz képest. Ha azon- 
ban a memóriaigényt is csökkenteni szeretnénk, illetve a kivételkezelést a C hívási sorrend- 
jével és a hibakeresők szabványos eljárásaival is össze szeretnénk egyeztetni, ha nem is 
lehetetlen, de nehéz feladatra vállalkozunk — de emlékezzünk arra, hogy a kivételek hasz- 
nálatának alternatívái sincsenek ingyen. Nem szokatlan olyan hagyományos rendszerekkel 
találkozni, amelyeknél a kód felét a hibakeresésre szánták. 
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Vegyünk egy egyszerű /O függvényt, amelynek látszólag semmi köze nincs a kivételkezeléshez: 


void g(inV); 

void JO 

( 
string s; 
KZáEYA 
81; 
g2; 


J 


Ám £0 kivételt válthat ki, így /0-nek tartalmaznia kell a kivétel fellépte esetén s-et megsem- 
misítő kódot. Ha g0 nem váltott volna ki kivételt, valamilyen más módon kellett volna a hi- 
bát jeleznie. Így a fentivel összehasonlítható hagyományos kód, amely kivételek helyett 
hibákat kezel, nem a fenti egyszerű kód lenne, hanem valami ilyesmi: 


bool g(in0); 
bool fO 
( 
string s; 
MESÉS 
if (g(1) 
if (2) 
return true; 
else 
return false; 
else 
return false; 


j 


A programozók szokás szerint persze nem kezelik ennyire módszeresen a hibákat, és az 
nem is mindig létfontosságú. De ha gondos és módszeres hibakezelés szükséges, akkor 
jobb azt a számítógépre, vagyis a kivételkezelő rendszerre hagyni. 


A kivételek specifikációja (414.6) nagyon hasznos lehet a fordító által létrehozott kód javí- 
tására. Ha az alábbi módon kijelentettük volna, hogy g0 nem vált ki kivételt, akkor az f0 
számára létrehozott kódon javíthattunk volna: 


void g(inb) throwO; 


Érdemes megjegyezni, hogy a hagyományos C függvények nem váltanak ki kivételt, így a leg- 
több programban az összes C függvény az üres throw kivétel-meghatározással adható meg. 
Az adott nyelvi változat tudhatja, hogy a C-nek csak néhány standard könyvtárbeli függvénye 
vált ki kivételt, például az atexit0 és a gsortO, és ennek ismeretében jobb kódot készíthet. 
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Mielőtt egy ,C függvényt" ellátnánk az üres kivétel-meghatározással (a throwO-val), gon- 
doljuk meg, nem válthat-e ki kivételt. Például átírhatták, hogy a new operátort használja, 
amely viszont bad alloc-ot válthat ki vagy olyan Ct-4-könyvtárat hívhat meg, amely ugyan- 
ezt teheti. 


14.9. A hibakezelés egyéb módjai 


A kivételkezelő eljárás célja, hogy lehetővé tegye egy programrész számára, hogy a prog- 
ram más részeit értesítse egy kivételes körülmény észleléséről. A feltevés az, hogy a két rész 
függetlenül készült és a kivételt kezelő rész tud valami értelmeset kezdeni a hibával. 


A kivételkezelők hatékony használatához átfogó stratégiára van szükségünk. Vagyis a prog- 
ram különböző részeinek egyet kell érteniük abban, hogyan használják a kivételeket és hol 
kezelik a hibákat. A kivételkezelő eljárás lényegénél fogva nem lokális, így alapvető jelen- 
tőségű, hogy átfogó stratégia érvényesüljön. Ebből következik, hogy a hibakezelés módjá- 
ra legjobb a rendszer tervezésének legkorábbi szakaszában gondolni, és hogy az alkalma- 
zott módszernek (a teljes program összetettségéhez képes0) egyszerűnek és pontosan meg- 
határozottnak kell lennie. Egy, a lényegénél fogva annyira kényes területen, mint a hibake- 
zelés, egy bonyolult módszerhez nem tudnánk következetesen alkalmazkodni. 


Először is fel kell adni azt a tévhitet, hogy az összes hibát egyetlen eljárással kezelhetjük; ez 
csak bonyolítaná a helyzetet. A sikeres hibatűrő rendszerek többszintűek. Mindegyik szint 
annyi hibával birkózik meg, amennyivel csak tud, anélkül, hogy túlságosan megszenvedne 
vele, a maradék kezelését viszont a magasabb szintekre hagyja. A terminateO ezt a kezelé- 
si módot azzal támogatja, hogy menekülési utat hagy arra az esetre, ha maga a kivételkeze- 
lő rendszer sérülne vagy nem tökéletes használata miatt maradnának nem elkapott kivéte- 
lek. Az unexbpectedŐ célja ugyanígy az, hogy menekülési utat hagyjon arra az esetre, ha 
a kivételek specifikációjára épülő hibakezelő rendszer mégsem jelentene a kivételek szá- 
mára áthatolhatatlan falat. 


Nem minden függvény kell, hogy , tűzfalként" viselkedjen. A legtöbb rendszerben nem le- 
het minden függvényt úgy megírni, hogy vagy teljes sikerrel járjon vagy egy pontosan 
meghatározott módon legyen sikertelen. Hogy ez miért nem lehetséges, az programról 
programra és programozóról programozóra változik. Nagyobb programok esetében a kö- 
vetkező okokat sorolhatjuk fel: 
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1. Túl sok munka kellene ennek a , megbízhatóságnak" olyan biztosításához, hogy 
következetesen mindenhol érvényesüljön. 

2. A szükséges tárterület és futási idő növekedése nagyobb lenne az elfogadhatónál 
(mert rendszeresen ugyanazon hibák - például érvénytelen paraméterek — ismé- 
telt ellenőrzésére kerül sor). 

3. Más nyelven írt függvények nem alkalmazkodnának a szabályokhoz. 

4. Ez a pusztán helyi értelemben vett , megbízhatóság?" olyan bonyolultsághoz ve- 
Zetne, amely végül aláásná a teljes rendszer megbízhatóságát. 


Ugyanakkor egy program olyan különálló részrendszerekre bontása, amelyek vagy teljes si- 
kerrel járnak, vagy meghatározott módon lesznek sikertelenek, alapvető, megtehető és gaz- 
daságos. Egy főbb könyvtárat, részrendszert vagy kulcsfontosságú függvényt így kell meg- 
tervezni. A kivételeket ilyen könyvtárak vagy részrendszerek felületei számára célszerű 
meghatározni. 


Rendszerint nem adatik meg az a luxus, hogy egy rendszer összes kódját , a nulláról" készít- 
hessük el. Ezért egy általános, minden programrészre kiterjedő hibakezelési stratégia meg- 
alkotásakor figyelembe kell vennünk az egyes, a miénktől eltérő módszert alkalmazó prog- 
ramrészleteket is. Ehhez pedig tekintetbe kell vennünk olyan kérdéseket, mint hogy a prog- 
ramrészlet hogyan kezeli az erőforrásokat, vagy milyen állapotba kerül egy hibája után 
a rendszer. Az a cél, hogy a programrészlet látszólag akkor is az általános hibakezelési mód- 


szer szerint kezelje a hibákat, ha valójában eltérő belső eljárást alkalmaz. 


Alkalmasint szükséges lehet az egyik stílusú hibajelzésről a másikra áttérni. Például egy C 
könyvtári függvény meghívása után ellenőrizhetjük az errno-t és kivételt válthatunk ki, 
vagy fordítva, elkaphatunk egy kivételt és az errno-t beállíthatjuk, mielőtt a C----könyv- 
tárból visszatérünk egy C programba: 


void calliCO throu(C blewit) 
t 
errno - 0; 
c functionO; 
if (errno) ( 
// takarítás (ha lehetséges és szükséges) 


throw C blewit(errno); 


J 


j 


extern "C" void call from CO throwO 
( 
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try ( 
c plus plus functionO; 

j 

catch (...)( 
// takarítás (ha lehetséges és szükséges) 
errno - E. CPLPLFCTBLEWIT; 

j 


) 


Ilyenkor fontos, hogy következetesen járjunk el, hogy a hibajelentő stílusok átalakítása 
teljes legyen. 


A hibakezelés - a lehetőségekhez mérten - hierarchikus legyen. Ha egy függvény futási ide- 
jű hibát észlel, ne kérjen segítséget vagy erőforrást a hívójától. Az ilyen kérések az egymás- 
tól függő elemek között körbe-körbe járó végtelen ciklusokat okoznak, ami a programot át- 
tekinthetetlenné teszi, a végtelen ciklusok lehetőségével pedig a hibákat kezelő kódba egy 
nem kívánatos lehetőséget épít. 


Alkalmazzunk olyan egyszerűsítő módszereket, mint a , kezdeti értékadás az erőforrás meg- 
szerzésévelP", illetve olyan egyszerűsítő feltevéseket, mint ,a kivételek hibákat jelentenek". 
Ezzel a hibakezelő kódot szabályosabbá tehetjük. Lásd még a §24.3.7.1 pontot, ahol elma- 
gyarázzuk, hogyan lehet állapotbiztosítókat (invariánsokat) és feltevéseket használni, hogy 


a kivételek kiváltása szabályosabb legyen. 


14.10. Szabványos kivételek 


A következő táblázat a szabványos kivételeket és az azokat kiváltó függvényeket, operáto- 
rokat, általános eszközöket mutatja be: 





Szabványos (a nyelvbe beépített) kivételek 











Név Kiváltó Hivatkozás Fejállomány 
bad alloc new 46.2.6.2, §19.4.5 cnew: 

bad cast dynamic cast §15.4.1.1 Ztypeinfo- 
bad typeid typeid §15.4.4 Ztypeinfo- 


bad exception kivétel specifikáció §14.6.3 Lexception: 
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Szabványos (a standard könyvtár által kiváltott) kivételek 
Név Ki dobja Hivatkozás Fejállomány 
out of range at0 §16.3.3,§20.3.3 stdexcept: 
bitsetc3::operator JO §17.5.3 cstdexcept: 
invalid argument bitset konstruktor 417.5.3.1 stdexcept: 
overflow error bitsetS:::to ulongO  §17.5.3.3 cstdexcept- 
ios base::failure . ios base::clearO §21.3.6 Zios2 











A könyvtári kivételek a standard könyvtár exception nevű — az Cexception: fejállományban 
megadott — kivételosztályból kiinduló osztályhierarchia tagjai: 


class exception f 
bublic: 
exceptionO throwO; 
exception(const exceptiond ) throwO; 
exceptionkg operator-(const exceptiond ) throwO; 
virtual -exceptionO throwO; 


virtual const char? whatO const throwO; 
brivate: 


LE sz 


J; 


A hierarchia így néz ki: 





exception 
logic error runtime error 
lenght error 
domain error range error 
out of range bad alloc bad cast overflow error 
invalid argument bad exception bad typeid underflow error 





ios base::failure 
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Ez meglehetősen körülményesnek tűnik ahhoz képest, hogy nyolc szabványos kivételt ölel 
fel. Oka, hogy a hierarchia megpróbál a standard könyvtárban meghatározott kivételeken 
kívüli kivételek számára is használható keretrendszert adni. A logikai hibák (ogic error) 
azok, amelyeket elvileg a program indulása előtt, függvény- vagy konstruktorparaméterek 
ellenőrzésével el lehetne kapni. A többi futási idejű hiba (run-time error). Némelyek ezt az 
összes hiba és kivétel számára hasznos keretrendszernek látják — én nem. 


A standard könyvtárbeli kivételek az exception által meghatározott függvényeket nem bő- 
vítik újakkal, csak megfelelően definiálják a megkívánt virtuális függvényeket. Így az aláb- 
bit írhatjuk: 


void JO 
try ( 
// a standard könyvtár használata 
j 
catch (exceptiong e) f 
cout c££ "standard könyvtári kivétel " SZ e.whatO cz Mi; // talán 
ZAB 
j 
catch (...) ( 
cout 2 "másik kivételNm"; 
less 
J 


A standard könyvtárbeli kivételek az exception-bőól származnak, a többi viszont nem feltét- 
lenül, így hiba lenne az összes kivételt az exception elkapásával megpróbálni lekezelni. Ha- 
sonlóan hiba lenne feltételezni, hogy az összes, az exception-ből származó kivétel standard 
könyvtárbeli kivétel, a felhasználók ugyanis hozzáadhatják saját kivételeiket az exception 
hierarchiához. 


Jegyezzük meg, hogy az expection-műveletek maguk nem váltanak ki kivételt. Ebből kö- 
vetkezően egy standard könyvtárbeli kivétel kiváltása nem vált ki bad alloc kivételt. A ki- 
vételkezelő rendszer fenntart a saját céljaira egy kis memóriát (például a veremben), hogy 
ott tárolhassa a kivételeket. Természetesen írhatunk olyan kódot, amely a rendszer összes 


íme egy függvény, amit ha meghívunk, kipróbálja, hogy a függvényhívásnál vagy a kivétel- 
kezelésnél fogy-e ki először a memória: 


void pervertedŐ 


( 
try( 


J 


throw exception; // ismétlődő kivétel 
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catch (exceptiong e) ( 
bervertedO; // ismétlődő függvényhívás 
cout c£ e.whatO; 


J 


j 


A kimeneti utasítás egyedül azt a célt szolgálja, hogy megakadályozza a fordítóprogramot 
az e nevű kivétel által felhasznált memória újrahasznosításában. 


14.11. Tanácsok 


[II] Hibakezelésre használjunk kivételeket. §14.1, §14.5, §14.9. 

[2] Ne használjunk kivételeket, ha a helyi vezérlési szerkezetek elégségesek. §14.1. 

[3] Az erőforrások kezelésére a , kezdeti értékadás az erőforrás megszerzésével" 
módszert használjuk. §14.4. 

I4l Nem minden programnak kell , kivételbiztosnak" lennie. §14.4.3. 

[5] Az invariánsok érvényességének megőrzésére használjuk a , kezdeti értékadás 
az erőforrás megszerzésével" módszert és a kivételkezelőket. §414.3.2. 

[6] Minél kevesebb try blokkot használjunk. Meghatározott kezelőkód helyett 
a , kezdeti értékadás az erőforrás megszerzésével" módszert használjuk. §14.4. 

[71 Nem minden függvénynek kell minden lehetséges hibát kezelnie. §14.9. 

[8] A konstruktorhibák jelzésére váltsunk ki kivételt. §14.9. 

[9] Ha egy értékadás vált ki kivételt, előtte gondoskodjon paramétereinek követke- 
Zetes állapotba hozásáról. §14.4.6.2. 

[10] A destruktorokban kerüljük a kivételek kiváltását. §14.4.7. 

[11] A mainŐ függvény kapja el és jelentse az összes hibát. §14.7. 

[12] Különítsük el a közönséges kódot a hibakezeléstől. §14.4.5 és §14.5. 

[13] Gondoskodjunk arról, hogy egy konstruktorban minden lefoglalt erőforrást fel- 
szabadítsunk, ha a konstruktor kivételt vált ki. §14.4. 

[14] Az erőforrások kezelése hierarchikus legyen. §14.4. 

[15] A főbb felületekben határozzuk meg az engedélyezett kivételeket. §14.9. 

[16] Legyünk résen, nehogy a new által lefoglalt és a kivételek fellépte esetén fel 
nem szabadított memória elszivárogjon. §14.4.1, 914.4.2, §14.4.4. 

[17] A függvényekről tételezzük fel, hogy minden kivételt kiválthatnak, amit megen- 
gedtek nekik. §14.6. 

[18] Ne tételezzük fel, hogy minden kivétel az exception osztály leszármazottja. 
§14.10. 

[19] Egy könyvtár ne fejezze be egyoldalúan a program futását. Ehelyett váltson ki 
kivételt és hadd döntsön a hívó. §14.1. 
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[20] Egy könyvtár ne bocsásson ki a végfelhasználónak szánt diagnosztikai üzenete- 
ket. Ehelyett váltson ki kivételt és hadd döntsön a hívó. §14.1. 
[21] A tervezés során minél hamarabb alakítsuk ki a hibakezelési stratégiát. 414.9 


14.12. Gyakorlatok 


1. (2) Általánosítsuk a §14.6.3.1 pontbeli S7C osztályt sablonná, amely a , kezdeti 
értékadás az erőforrás megszerzésével" módszert használja különféle típusú 
függvények tárolására és visszaállítására. 

2. C3) Egészítsük ki a §11.11 pontbeli Ptir. to T osztályt mint egy olyan sablont, 
amely kivételekkel jelzi a futási idejű hibákat. 

3. (3) Írjunk függvényt, amely egy bináris fa csúcsaiban keres egy char? típusú 
mező alapján. A hello-t tartalmazó csúcs megtalálásakor a find( hello") a csúcsra 
hivatkozó mutatóval térjen vissza; a keresés sikertelenségét kivétellel jelezzük. 

4. C3.) Hozzunk létre egy /nt osztályt, amely pontosan úgy viselkedik, mint az 
elemi int típus, csak túl- és alulcsordulás esetén kivételt vált ki. 

5. (2.5) Vegyük a felhasznált operációs rendszer C felületének állományok meg- 
nyitására, lezárására, olvasására, írására való alapvető műveleteit, és írjunk hoz- 
zájuk egyenértékű C--4 függvényeket, amelyek a megfelelő C függvényeket hív- 
ják meg, de hiba esetén kivételt váltanak ki. 

6. (2.5) Írjunk egy teljes Vector sablont Range és Size kivételekkel. 

7. (1) Írjunk egy ciklust, ami kiszámítja a §14.12[61-beli Vector összegét a Vector 
méretének lekérdezése nélkül. Ez miért nem jó ötlet? 

8. (2.5) Gondoljuk meg, mi lenne, ha egy Exception osztályt használnánk az 
összes kivételként használt osztály őseként (bázisosztályakénb9. Hogyan nézne 
ki? Hogyan lehetne használni? Mire lenne jó? Milyen hátrányok származnának 
abból a megkötésből, hogy ezt az osztályt kell használni? 

9. 1) Adott a következő függvény: 


int mainO0 f/? ... "/) 


Változtassuk meg úgy, hogy minden kivételt elkapjon, hibaüzenetté alakítsa 
azokat, majd meghívja az abortO-ot. Vigyázat: a §14.9 pontbeli call from CO 
függvény nem teljesen kezel minden esetet. 

10. (2) Írjunk visszahívások (callback) megvalósítására alkalmas osztályt vagy 
sablont. 

11.(2.5) Írjunk egy Zock osztályt, amely valamely rendszer számára a konkurens 
hozzáférést támogatja. 
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Osztályhierarchiák 


, Az absztrakció szelektív tudatlanság." 
(Andrew Koenig) 


Többszörös öröklődés s A többértelműség feloldása s Öröklődés és using deklaráci- 
ók "e Ismétlődő bázisosztályok s Virtuális bázisosztályok s A többszörös öröklődés haszná- 
lata s Hozzáférés-szabályozás s Védett tagok s Bázisosztályok elérése e Futási idejű típus- 
információ e dynamic cast s Statikus és dinamikus konverzió e typeid s Kiterjesztett típus- 
információ se A futási idejű típusinformáció helyes és helytelen használata e Tagra hivatko- 
zó mutatók s Szabad tár e , Virtuális konstruktorok" e Tanácsok s Gyakorlatok 


15.1. Bevezetés és áttekintés 


Ez a fejezet a származtatott osztályoknak és a virtuális függvényeknek a más nyelvi elemek- 
kel, például a hozzáférés-szabályozással, a névfeloldással, a szabad tár kezelésével, 
a konstruktorokkal, a mutatókkal és a típuskonverziókkal való kölcsönhatását tárgyalja. Öt 
fő részből áll: 


§15.2 Többszörös öröklődés 
§15.3 Hozzáférés-szabályozás 
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§15.4 Futási idejű típusazonosítás 
§15.5 Tagokra hivatkozó mutatók 
§15.6 A szabad tár használata 


Az osztályokat általában bázisosztályok , hálójából" hozzuk létre. Mivel a legtöbb ilyen há- 
ló hagyományosan fa szerkezetű, az osztályokból álló hálókat vagy osztályhálókat (class 
lattice) gyakran nevezik osztályhierarchiának Cclass hierarchy) is. Az osztályokat célszerű 
úgy megtervezni, hogy a felhasználóknak ne kelljen indokolatlan mértékben azzal törődni- 
ük, hogy egy osztály milyen módon épül fel más osztályokból. Így például a virtuális függ- 
vények meghívási módja biztosítja, hogy ha egy /0 függvényt meghívunk egy objektumra, 
akkor mindig ugyanaz a függvény hajtódik végre, függetlenül attól, hogy a hierarchia me- 
lyik osztálya deklarálta a függvényt a meghíváshoz. Ez a fejezet az osztályhálók összeállítá- 
sának és az osztálytagok elérésének módjairól, illetve az osztályhálók fordítási és futási ide- 
jű bejárásának eszközeiről szól. 


15.2. Többszörös öröklődés 


Ahogy a 42.5.4 és §12.3 pontokban láttuk, egy osztálynak több közvetlen bázisosztálya is le- 
het, azaz több osztályt is megadhatunk a : jel után az osztály deklarációjában. Vegyünk egy 
szimulációs programot, ahol a párhuzamos tevékenységeket a 7ask (Feladat) osztállyal, az 
adatgyűjtést és -megjelenítést pedig a Disblayed (Megjelenítés) osztállyal ábrázoljuk. Ekkor 
olyan szimulált egyedeket határozhatunk meg, mint a Satellite (Műhold): 


class Satellite : public Task, public Displayed f 
ez 


J; 


Több közvetlen bázisosztály használatát szokás szerint többszörös öröklődésnek (multiple 
inheritance) nevezik. Az egyszeres öröklődésnél (single inheritance) csak egy közvetlen 
bázisosztály van. 


A Satellite-okra saját műveleteiken kívül a 7ask-ok és Displayed-ek műveleteinek uniója is 
alkalmazható: 


void (Satellite s) 

( 
s.drawO; // Displayed::drawO 
s.delay(109;  // Task::delayO 
s.transmitO;  // Satellite::transmitO 
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Hasonlóan, ha egy függvény Jask vagy Displayed paramétert vár, akkor adhatunk neki egy 
Satellite-ot is: 


void highlight Displayed" ); 
void suspend(Task" ); 


void g(Satellite? p) 


( 
highlight(p); // mutató átadása a Satellite Displayed részére 
suspend(p);  // mutató átadása a Satellite Task részére 


J 


A program létrehozása nyilván valamilyen egyszerű eljárás alkalmazását követeli meg a for- 
dítóprogramtól, hogy a 7ask-ot váró függvények más részét lássák egy Saztellite-nak, mint 
a Displayed-et várók. A virtuális függvények a megszokott módon működnek: 


class Task f 
VÜET 
virtual void pendingO —- 0; 


J; 
class Displayed ( 
VAK 
virtual void drawO — 0; 
j; 
class Satellite : public Task, public Displayed ( 
VALE 
void pendingO; // felülírja a Task::pendingO függvényt 
void drawO; // felülírja a Displayed::drawO függvényt 


Vai 


Ez biztosítja, hogy Satellite::drawO, illetve Satellite::bendingO fog meghívódni, ha egy 
Satellite-ot Disblayed-ként, illetve 7ask-ként kezelünk. 


Jegyezzük meg, hogy ha csak egyszeres öröklődést használhatnánk, akkor ez a körülmény 
korlátozná a programozót a Satellite, Disblayed és Task osztályok megvalósításának megvá- 
lasztásában. Egy Satellite vagy Task, vagy Displayed lehetne, de nem mindkettő (hacsak 
a Task nem a Displayed-ből származik vagy fordítva). Ezen lehetőségek mindegyike csök- 
kenti a rugalmasságot. 


Mi szüksége lehet bárkinek egy Satellite osztályra? Nos, bármilyen meglepő, a Satellite pél- 
dát a valóságból merítettük. Volt — és talán még mindig van — egy olyan program, amely 
a többszörös öröklődés leírására itt használt minta szerint épült fel. A program műholdakat, 
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földi állomásokat stb. magába foglaló hírközlési rendszerek szerkezetének tanulmányozá- 
sára szolgált. Egy ilyen szimuláció birtokában meg tudjuk válaszolni a forgalmi adatokra vo- 
natkozó kérdéseket, meg tudjuk határozni, mi történik, ha egy földi állomást vihar akadá- 
lyoz, műholdas és földi kapcsolatok előnyeit-hátrányait tudjuk elemezni stb. A különböző 
körülmények utánzása számos megjelenítési és hibakeresési műveletet igényel, és szükség 
van a Satellite-okhoz hasonló objektumok, illetve részegységeik állapotának tárolására is, 
az elemzés, illetve a hibakeresés és -elhárítás céljából. 


15.2.1. A többértelműség feloldása 
Két bázisosztálynak lehetnek azonos nevű tagfüggvényei is: 


class Task f 
F/AKo8 
virtual debug info" get debugO; 


J; 


class Displayed ( 
Vé 
virtual debug info" get debugO; 


Ha egy Satellite-ot használunk, akkor ezeket a függvényeket egyértelműen kell meg- 
neveznünk: 


void (Satellite? sp) 


( 
debug info" dip - sp-2get debugO; // hiba: többértelmű 
dip -— sp-2Task::get debugO; // rendben 
dip - sp--Displayed::get debugO; // rendben 


Az explicit megnevezés azonban zavaró, ezért általában legjobb elkerülni az ilyen problémá- 
kat. Ennek legegyszerűbb módja, ha a származtatott osztályban készítünk egy új függvényt: 


class Satellite : public Task, public Displayed f 
VAN 


debug info" get debugO // felülírja a Task::get debugO és 
// Displayed::get debugO függvényeket 
( 
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debug info" dip1 - Task::get debugO; 
debug info" dip2 - Displayed::get debugO; 
return dip1--merge(dip29; 


Ezáltal a Satellite bázisosztályaira vonatkozó információk felhasználását helyhez kötöttük. 
Mivel a Satellite::get debugO elfedi mindkét bázisosztályának get debugO függvényét, 
a Satellite::get debugO hívódik meg, valahányszor get debugO-ot hívunk meg egy Satellite 
objektumra. 


A Telstar::draw minősített név a 7elstar-ban vagy valamelyik bázisosztályában megadott 
draw-ra vonatkozhat: 


class Telstar : public Satellite ( 


Se 

void drawO 

t 
drawO; // hoppá!: rekurzív hívás 
Satellite::drawO; // megtalálja a Displayed::draw-t 
Displayed::drawO; 
Satellite:: Displayed::drawO; // felesleges kétszeri minősítés 

J 


Vagyis ha a Satellite::draw nem a Satellite osztályban bevezetett draw-t jelenti, akkor a for- 
dítóprogram végignézi a bázisosztályokat, vagyis Task::draw-t és Disblayed::draw-t keres. 
Ha csak egyet talál, akkor azt fogja használni, ha többet vagy egyet sem, a Satellite::draw 
ismeretlen vagy többértelmű lesz. 


15.2.2. Öröklődés és using deklarációk 


A túlterhelés feloldására nem kerül sor különböző osztályok hatókörén keresztül (47.49, 
a különböző bázisosztályok függvényei közötti többértelműségek feloldása pedig nem tör- 
ténik meg a paramétertípus alapján. 


Egymással alapvetően nem rokon osztályok egyesítésekor, például a Task és Displayed osz- 
tályok Satellite-té való ,összegyúrásánál" az elnevezésekben megmutatkozó hasonlóság ál- 
talában nem jelent közös célt. Amikor az ilyen nevek ütköznek, ez gyakran meglepetésként 
éri a felhasználót: 
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class Task f 


VAN 
void debug(double p); // információ kiírása csak akkor, ha a prioritás 
// alacsonyabb p-nél 
J; 
class Displayed ( 
S. 


void debug(int v); // minél nagyobb v," annál több hibakeresési információ íródik ki 


J; 


class Satellite : public Task, public Displayed ( 


Zsó 
J; 
void g(Satellite? p) 
( 
b-2debug(1; // hiba, többértelmű: Displayed::debug(int) vagy 
// Task::debug(double) ? 
b-2Task::debug( U; // rendben 
b--Displayed::debug( 1; // rendben 


J 


De mi van akkor, ha a különböző bázisosztályokban tudatos tervezési döntés következté- 
ben szerepelnek azonos nevek, és a felhasználó számára kívánatos lenne a paramétertípus 
alapján választani közülük? Ebben az esetben a függvényeket a using deklarációval (48.2.2) 
hozhatjuk közös hatókörbe: 


class A ( 

bublic: 
int fin); 
char (char); 
Ms 


j; 
class Bf 

bublic: 

double f(iddouble); 
ZANA 


3; 
class AB: public A, public B f 
bublic: 
using A::f; 
using B::f; 
char f((char); // elfedi A::fchar)-t 
AB (AB); 
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void ((AB£k ab) 


ab fOD: // A: fin) 

ab fCa)); // AB::f(char) 
ab f(2.0); // B::f(double) 
ab f(ab): // AB: TAB) 


J 


A using deklarációk lehetővé teszik, hogy a bázis- és származtatott osztályok függvényei- 
ből túlterhelt függvények halmazát állítsuk elő. A származtatott osztályban megadott függ- 
vények elfedik (hide) a bázisosztály függvényeit, amelyek egyébként elérhetőek lennének. 
A bázisosztály virtuális függvényei ugyanúgy felülírhatók (override), mint egyébként 


(§15.2.3.1. 


Egy osztálydeklaráció using deklarációjának (48.2.2) egy bázisosztály tagjára kell vonatkoz- 
nia. Egy osztály tagjára vonatkozó using deklaráció nem szerepelhet az osztályon, annak 
származtatott osztályán, illetve annak tagfüggvényein kívül, a using direktívák (48.2.3) pe- 
dig nem szerepelhetnek egy osztály definiciójában és nem vonatkozhatnak osztályra. 


A using deklarációk nem szolgálhatnak kiegészítő információ elérésére sem, csak az egyéb- 


ként is hozzáférhető információk kényelmesebb használatát teszik lehetővé (§15.3.2.29. 


15.2.3. Ismétlődő bázisosztályok 


Azáltal, hogy több bázisosztály lehet, előfordulhat, hogy egy osztály kétszer fordul elő a 
bázisosztályok között. Például ha mind a 7ask, mind a Displayed a Link(Kapcsolat) osztály- 
ból származott volna, a Satellite-oknak két Link-je lenne: 


struct Link ( 
Link? next; 


Vö 


class Task : public Link f( 
// a Link-et a Task-ok listájához (az ütemező listához) használjuk 
VA 

j; 


class Displayed : public Link ( 
// a Link-et a Displayed objektumok listájához (a megjelenítési listához) használjuk 
VES 

j; 
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Ez nem gond. Két külön Zink objektum szolgál a listák ábrázolására és a két lista nem Za- 
varja egymást. Természetesen a Link osztály tagjaira nem hivatkozhatunk a kétértelműség 
veszélye nélkül (§15.2.3.10. Egy Satellite objektumot így rajzolhatunk le: 


Link Link 


MS SÉRE Má Displayed 


Satellite 


Ha a közös bázisosztályt nem szabad két külön objektummal ábrázolni, virtuális bázisosz- 
tályokat (415.2.4) alkalmazhatunk. 


A Link-hez hasonlóan többször szereplő bázisosztályok olyan elemek, amelyeket nem sza- 
bad a közvetlenül öröklő osztályon kívül használni. Ha egy ilyen osztályra olyan pontról 
kell hivatkozni, ahonnét annak több példánya is látható, a többértelműség elkerülése érde- 
kében a hivatkozást minősíteni kell: 


void mess with links(Satellite? p) 


( 
b-2next - 0; // hiba: többértelmű (melyik Link?) 
b-Link::next - O; // hiba: többértelmű (melyik Link?) 
b--Task::Link::next — O; // rendben 
b-Displayed::Link::next — O; // rendben 
Ma 


Ez pontosan ugyanaz az eljárás, mint amit a tagokra való többértelmű hivatkozások felol- 
dására használunk (§15.2.19. 


15.2.3.1. Felülírás 


A többször szereplő bázisosztályok valamely virtuális függvényét a származtatott osztály 
(egyetlen) függvénye felülírhatja (felülbírálhatja, override). Egy objektumnak saját magát 
egy fájlból kiolvasni vagy oda visszaírni való képességét például így ábrázolhatjuk: 


class Storable f 

bublic: 
virtual const char" get file0 - 0; 
virtual void readÓ 7 0; 
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virtual void writeO) — 0; 
virtual -Storable0 f ) 
j; 
Természetesen több felhasználó építhet erre, hogy olyan osztályokat írjon, amelyek függet- 
lenül vagy együtt használva jobban kidolgozott osztályokat adnak. Például leállíthatunk és 


újraindíthatunk egy szimulációt, ha mentjük az alkotóelemeket és később visszaállítjuk azo- 


kat. Ezt az ötletet így valósíthatjuk meg: 


class Transmitter : public Storable f 
bublic: 

void writeO; 

ÚT sin 
j; 


class Receiver : public Storable ( 
bublic: 

void writeO; 

VAS 
j; 


class Radio : public Transmitter, public Receiver f 
bublic: 

const char" get fileO; 

void readO; 

void writeO; 

ZÁGES 
j; 


A felülíró függvény általában meghívja a bázisosztálybeli változatokat és a származtatott 


osztályra jellemző tennivalókat végzi el: 


void Radio::writeO) 


( 

Transmitter:: write); 

Receiver::writeO); 

// kiírja a Radio-ra jellemző adatokat 
J 


Az ismétlődő bázisosztályokról származtatott osztályokra való típuskonverziót a §15.4.2 
pont írja le. Arról, hogyan lehet az egyes write0 függvényeket a származtatott osztályok kü- 
lön függvényeivel felülírni, a §25.6 pont szól. 
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15.2.4. Virtuális bázisosztályok 


Az előző pont Radio példája azért működik, mert a Storable osztályt biztonságosan, kényel- 
mesen és hatékonyan lehet többszörözni. Ez azonban az olyan osztályok esetében rendsze- 
rint nem igaz, amelyek jó építőkövei más osztályoknak. A Storable osztályt például úgy is 
meghatározhatnánk, mint ami tartalmazza az objektum mentésére használt fájl nevét: 


class Storable f 
bublic: 
Storable(const char" 5); 
virtual void readO — 0; 
virtual void writeO — 0; 
virtual -StorableO; 
brivate: 
const char"? store; 


Storable(const Storabledt ); 
Storablek operator—(const Storabled ); 


A Storable ezen látszólag csekély módosítása után meg kell változtatnunk a Radio szerke- 
Zetét is. Az objektum összes része a Storable azonos példányán kell, hogy osztozzék; külön- 
ben szükségtelenül nehéz feladat lenne az objektum többszöri tárolásának megakadályozá- 
sa. A virtuális bázisosztályok (virtual base class) ezt a megosztást segítik. A származtatott 
osztály minden virtuális bázisosztályát ugyanaz a (megosztot?) objektum ábrázolja: 


class Transmitter : public virtual Storable f( 
bublic: 
void writeO; 


A at 


J; 
class Receiver : public virtual Storable f 
bublic: 

void write; 


ási 


J; 
class Radio : public Transmitter, public Receiver f 
bublic: 

void write; 


Ms 
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Ábrával: 


Storable 


Receiver Transmitter 


TE lge gegzeezÉEÉS 


Hasonlítsuk össze ezt az ábrát a Satellite objektum §15.2.3-beli rajzával, hogy lássuk a kü- 
lönbséget a közönséges és a virtuális öröklődés között. Az öröklődési grátban egy adott ne- 
vű osztály minden virtuálisként megadott bázisosztályát az osztály egyetlen objektuma áb- 
rázolja, a nem virtuális bázisosztályokat viszont saját részobjektumuk. 


15.2.4.1. Virtuális bázisosztályok programozása 


Amikor a programozó függvényeket készít egy olyan osztály számára, amelynek virtuális 
bázisosztálya van, nem tudhatja, hogy a bázisosztályt meg kell-e osztani egyéb származta- 
tott osztályokkal, ami gondot jelenthet, ha egy szolgáltatást úgy kell megvalósítani, hogy a 
bázisosztály egy adott függvényének meghívására pontosan egyszer kerüljön sor, például 
mert a nyelv előírja, hogy egy virtuális bázisosztály konstruktora csak egyszer futhat le. 
A virtuális bázisosztály konstruktorát a teljes objektum, azaz a legtávolabbi származtatott 
osztály konstruktora hívja meg (automatikusan vagy közvetlenül: 


class A ( // nincs konstruktor 
KÉS 
vő 


class B (f 

bublic: 
BO; // alapértelmezett konstruktor 
V/ANO 

3 


class C (f 
bublic: 
C(inD; // nincs alapértelmezett konstruktor 


); 
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class D : virtual public A, virtual public B, virtual public C 


( 
DOTAuHHT // hiba: C-nek nincs alapértelmezett konstruktora 
D(Gnt 9: CV (A... 7); // rendben 
28 


J; 


A virtuális bázisosztály konstruktora a származtatott osztályok konstruktora előtt hívódik 
meg. Szükség esetén a programozó ezt a működést utánozhatja is, ha a virtuális bázisosz- 
tály függvényét csak a legtávolabbi származtatott osztályból hívja meg. Tegyük fel, hogy 
van egy alapvető Window osztályunk, amely ki tudja rajzolni tartalmát: 


class Window ( 
// alapkód 
virtual void drawO; 


J; 


Az ablakokat emellett többféle módon díszíthetjük és szolgáltatásokkal egészíthetjük ki: 


class Window with border : public virtual Window f 
// a szegély kódja 
void own drawO; //a szegély megjelenítése 
void drawO; 

b 

class Window with menu : public virtual Window f 
// a menü kódja 
void own drawO; // a menü megjelenítése 
void drawO; 


J; 


Az own drawO függvényeknek nem kell virtuálisaknak lenniük, mert egy virtuális drawO 


függvényből akarjuk meghívni azokat, ami pontosan ismeri az objektum típusát, amelyre 
meghívták. 


Ebből egy működőképes Clock osztályt állíthatunk össze: 


class Clock : public Window with border, public Window with menu (f 
// az óra kódja 
void own drawO; // az óralap és a mutatók megjelenítése 
void drawO; 
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Ábrával: 


Window 


Window with border Window with menu 


TES gs zetzzzzát 1 


A drau0 függvényeket most már úgy írhatjuk meg az own drawO függvények felhasználá- 
sával, hogy bármelyik drawO meghívása pontosan egyszer hívja meg a Window::drawO-t, 
függetlenül attól, milyen fajta Window-ra hívták meg: 


void Window with border::drawO 


( 

Window::drawO; 

own drawO; // a szegély megjelenítése 
9. 
void Window with menu::drawO 
( 

Window::drawO; 

own drawO; // a menü megjelenítése 
J 
void Clock::drawO 
( 

Window::drawO; 

Window with border::own drawO); 

Window with menu::own drawO; 

own drawO; // az óralap és a mutatók megjelenítése 
) 


A virtuális bázisosztályokról származtatott osztályokra való konverziót a §15.4.2 pont írja le. 


15.2.5. A többszörös öröklődés használata 


A többszörös öröklődés legegyszerűbb és legnyilvánvalóbb felhasználása két egyébként 
egymással rokonságban nem álló osztály , összeragasztása" egy harmadik osztály részeként. 
A Task és Displayed osztályokból a §15.2 pontban összerakott Satellite osztály is ilyen. 
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A többszörös öröklődés ilyen módon való használata egyszerű, hatékony és fontos — de nem 
túl érdekes, hiszen alapjában véve csak a továbbító függvények megírásától kíméli meg 
a programozót. Az eljárás nem befolyásolja számottevően a program általános szerkezetét és 
alkalmasint ütközhet azzal a kívánalommal, hogy a megvalósítás részletei maradjanak rejtve. 
Egy módszernek azonban nem kell , okosnak" lennie ahhoz, hogy hasznos legyen. 


A többszörös öröklődés használata absztrakt osztályok készítésére már nagyobb jelentősé- 
gű, annyiban, hogy befolyásolja a program tervezésének módját. A §412.4.3-beli 
BB ival slider osztály egy példa erre: 


class BB. ival slider 
: public Ival slider — // felület 
, protected BBslider . // megvalósítás 


( 
// az IWval slider" és a BBslider" által igényelt függvények megvalósítása 
// a "BBsSlider! szolgáltatásainak használata 


J; 


Ebben a példában a két bázisosztály logikailag különböző szerepet játszik. Az egyik egy 
nyilvános absztrakt osztály, amely a felületet nyújtja, a másik pedig egy védett (protected) 
konkrét osztály, amely a megvalósításról gondoskodik. A kétféle szerep az osztályok stílu- 
sában és az alkalmazott hozzáférési szabályokban tükröződik. A többszörös öröklődés sze- 
repe itt lényegbevágó, mert a származtatott osztálynak mind a felület, mind a megvalósítás 
virtuális függvényeit felül kell írnia. 

A többszörös öröklődés lehetővé teszi a testvérosztályok számára, hogy egyetlen közös ős 
jelentette függés bevezetése nélkül osztozhassanak adatokon. Ez az eset, amikor az úgyne- 
vezett káró alakú öröklődés (diamond-shaped inheritance) lép fel. (Lásd a Radio (§15.2.4) 
és a Clock (§15.2.4.1) példákat.) Ha a bázisosztály nem ismételhető, akkor virtuális (és nem 
közönséges) bázisosztályra van szükség. 


Az én véleményem az, hogy a káró alakú öröklési háló akkor kezelhető a legjobban, ha 
vagy a virtuális bázisosztály vagy a belőle közvetlenül származó osztályok absztraktak. Ve- 
gyük például újra a §12.4 pont /val box osztályait. Ott végül az összes Ival box osztályt 
absztrakttá tettük, hogy kifejezzük szerepüket, vagyis hogy kizárólag felületek. Ez lehetővé 
tette, hogy a lényegi programkód minden részét a megfelelő megvalósító osztályokba rejt- 
sük, és az egyes részeken való osztozás is csak a megvalósítás céljára használt ablakozó 
rendszer klasszikus hierarchiájában történt. 


Persze lenne értelme annak, hogy a Popup iíval slider-t megvalósító osztály nagy része kö- 


zös legyen a sima J/val slider-t megvalósító osztályéval, így az adatbekérő mezők kezelésén 
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kívül azonosak lennének. Ekkor az is természetes lenne, hogy az előálló csúszka-osztály- 
ban elkerüljük az /val slider objektumok ismétlődését. Ehhez az J/val slider-t virtuálissá 
tesszük: 


class BB ival slider : public virtual Ival slider, protected BBslider f /£ ... "/ ); 
class Popup ival slider : public virtual Ival slider€/£ ..."/ 3; 
class BB popup ival slider 

: public virtual Popup ival slider, protected BB ival sliderf /£ ..."/); 


Ábrával: 
Ival slider BBsSlider 
Popup ival slider BB i val slider 
NE d 


BB popup ival slider 


Könnyen elképzelhetjük a Pobpup ival slider-ből származó további felületeket és az azok- 
ból és a BB pobpup ival slider-ből származó további megvalósító osztályokat. 


Ha az ötletet végigvisszük, akkor a program felületét képező absztrakt osztályokból való min- 
den származtatást virtuálissá teszünk. Ez valóban a leglogikusabb, legáltalánosabb, és legru- 
galmasabb megoldásnak tűnik. Hogy miért nem tettem ezt, annak egyrészt a hagyományok 
figyelembe vétele az oka, másrészt a virtuális bázisosztályok megvalósításának legnyilvánva- 
lóbb és leggyakoribb módszerei annyira hely- és időigényesek, hogy kiterjedt használatuk 
egy osztályon belül nem vonzó. Mielőtt ez a tárigényben és futási időben mért költség vissza- 
riasztana bennünket egy más szemszögből vonzó szerkezet választásától, gondoljuk meg, 
hogy az Ival box-ot ábrázoló objektum általában csak egy mutatót tartalmaz a virtuális 
táblára. Ahogy a §15.2.4 pontban láttuk, egy változókat nem tartalmazó absztrakt osztály ve- 
szély nélkül ismételhető. Így a virtuális bázisosztály helyett közönségeset alkalmazhatunk: 


class BB ival slider : public Ival slider, protected BBslider £ /£ ... "/ ); 
class Popup ival slider : public Ival slider€/ ..."/); 
class BB popup ival slider 

: public Popup ival slider, protected BB ival slider€f/? ..."/ 3; 
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Ábrával: 
Ival slider Ival slider BBs$lider 
Popup ival slider BB ival slider 
VE. 


BB bopup ival slider 


Ez valószínűleg megvalósítható, optimalizált változata az előzőekben bemutatott, bevallot- 
tan világosabb szerkezetnek. 


15.2.5.1. A virtuális bázisosztályok függvényeinek felülírása 


A származtatott osztályok felülírhatják (override) közvetlen vagy közvetett virtuális bázis- 
osztályaik virtuális függvényeit. Két különböző osztály akár a virtuális bázisosztály külön- 
böző függvényeit is felülírhatja, így több származtatott osztály járulhat hozzá a virtuális 
bázisosztály által adott felület megvalósításához. A Window osztálynak lehetnek például 
set colorO és promptO függvényei. Ekkor a Window with border felülbírálhatja 
a set colorO-t, mint a színellenőrző séma részét, a Window with menu pedig a promptO- 
ot, mint a felhasználói felület kezelésének részét: 


class Window ( 
Mi 
virtual void set color(Color) — O; // háttérszín beállítása 
virtual void promptO —- 0; 


J; 


class Window with border : public virtual Window f 

zése 

void set color(Color); // háttérszín kezelése 
Vá 
class Window with menu : public virtual Window f 


HM vez 
void promptO; // felhasználói tevékenységek kezelése 
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class My window : public Window with menu, public Window with border ff 
VZGVSN 
3; 


Mi történik, ha különböző származtatott osztályok ugyanazt a függvényt írják felül? Ez csak 
akkor megengedett, ha az egyik származtatott osztály minden olyan osztály örököse, amely 
felülírja a függvényt, vagyis egy függvénynek az összeset felül kell írnia. A My window pél- 
dául felülírhatja a bpromptO-t, hogy a Window with menu-belinél jobb változatot adjon: 


class My window : public Window with menu, public Window with border ff 
ezt 


void promptO;// a felhasználói tevékenységek kezelését nem hagyjuk a bázisosztályra 


J; 
Ábrával: 
Window f set colorO, promptO ) 
Window with border f set colorO )? Window with menu f( promptO ? 


TS 


My window ( promptO ) 


Ha két osztály felülír egy bázisosztálybeli függvényt, de a két függvény egyike nem írja felül 
a másikat, akkor az osztályhierarchia hibás. Ilyenkor nem lehet virtuális függvénytáblát épí- 
teni, mert a teljes objektumra vonatkozó függvényhívás kétértelmű lenne. Például ha 
a §15.2.4. pontbeli Radio nem adta volna meg a writeO függvényt, akkor a Receiver és 
Transmitter osztályokbeli write0 deklarációk a kadio-ban hibát okoztak volna. Mint 
a Radio esetében is, az ilyen konfliktust a felülíró függvénynek a legtávolabbi származtatott 
osztályból való meghívásával oldhatjuk meg. 


Az olyan osztályokat, amelyek egy virtuális bázisosztály némelyik (de nem mindegyik) 
függvényének megvalósítását tartalmazzák, gyakran , mixin"-nek nevezik. 
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15.3. Hozzáférés-szabályozás 


Egy osztálytag lehet privát (private), védett (protected) vagy nyilvános (public): 


6 Ha privát, a nevét csak a tagfüggvényekben és a deklaráló osztály barátaiban 
(riend-jeiben) lehet felhasználni. 

6 Ha védett, a nevét csak a deklaráló osztály és barátai tagfüggvényeiben, vala- 
mint az osztályból származtatott osztályok és barátaik tagfüggvényeiben lehet 
felhasználni. 

4 Ha nyilvános, a nevét mindenhol fel lehet használni. 


Ez azt a nézetet tükrözi, hogy egy osztályt háromféle függvény érhet el: az osztályt megva- 
lósító függvények (azaz a barátok és a tagok), egy származtatott osztályt megvalósító függ- 


vények (azaz a származtatott osztályok barátai és a tagok), és az egyéb függvények. Ezt így 
ábrázolhatjuk: 


általános felhasználók 
származtatott osztály tagfüggvényei és barátai 


saját tagfüggvények és barátok 





nyilvános: v 


védett: 


privát: Y 


A hozzáférési szabályok egyöntetűen vonatkoznak a nevekre. Hogy a név mit jelöl, az 








érdektelen a hozzáférés szempontjából. Ez azt jelenti, hogy ugyanúgy lehetnek privát tag- 
függvények, típusok, állandók stb., mint privát adattagok. Például egy hatékony nem tola- 
kodó (non-intrusive, §16.2.1) listaosztálynak valószínűleg szüksége van az elemeket nyil- 
vántartó adatszerkezetekre. Az ilyen információ legjobb, ha privát: 


templatecxciass T- class List f( 
Dbrivate: 
struct Link f T val; Link" next; ); 
struct Chunk ( 
enum f chunk size — 15 3; 
Link ulchunk sizel; 
Chunk: next; 
2; 
Chunk" allocated; 
Link" free; 
Link" get freecO; 
Link? head; 
bublic: 
class Underflow ( ?; // kivételosztály 


void insert( D; 
T getO; 
Je 

Hz 


templatexciass T- void ListST-::insert( T val) 
f 

Link" Ink - get frecO; 

Ink-sval — val; 

Ink-:2next — head; 

head - Ink; 
j 


templatexclass T2 LisizT2::Link? ListzZT:::get freeO 
( 
if (ree -—- 0) ( 
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// új Chunk lefoglalása és Link-jeinek a szabad listára helyezése 


J 

LIink" p - free; 
JÍfree - free-2next; 
return p; 


J 


templatexclass T- T ListzZT:::getŐ 
if (head —- 0) throw UnderflowO; 


Link" p- head; 

head - p-2next; 
b--next - free; 

free - p; 


return p-2val; 


529 
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A ListZTI: hatókörbe azáltal lépünk be, hogy a tagfüggvényben ListST-::-t írunk. Mivel 
a get freeO visszatérési értékét előbb említjük, mint a ListST:::get freeO nevet, a Link rövi- 
dítés helyett a teljes ListST-::Link nevet kell használnunk. A nem tag függvényeknek - a ba- 
rát (friend) függvények kivételével — nincs ilyen hozzáférésük: 


void would be meddler(listzTet p) 


(t 
ListzT2::Link? g - O; // hiba: ListZT2::Link privát 
ge 
g - p-efree; // hiba: ListZT2::free privát 
leső 
if (TistzT:::Chunk::chunk size: 31 (f // hiba: LiSsIZT:::Chunk::chunk size privát 
V/ATO 
J 
) 


Az osztályok (class) tagjai alapértelmezés szerint privátok (private), a struktúrák (struct) tag- 
jai nyilvánosak (public, §10.2.8). 


15.3.1. Védett tagok 


A védett (protected) tagok használatának bemutatására vegyük a §415.2.4.1 pontbeli 
Window példát. Az own drawO függvények (akarattal) nem teljes körű szolgáltatást ad- 
nak. Arra a célra terveztük őket, hogy csak a származtatott osztályok számára szolgáljanak 
építőkövekül, az általános felhasználás számára nem biztonságosak, nem kényelmesek. 
Másfelől a drawO műveletek az általános felhasználást szolgálják. Ezt a különbséget 
a Window osztály felületének két, egy védett és egy nyilvános felületre való szétválasztásá- 
val lehet kifejezni: 


class Window with border ( 
bublic: 

virtual void drawO; 

Mé sé; 
brotected: 

void own drawO; 

// egyéb kirajzoló kód 
brivate: 

// ábrázolás stb. 


J; 
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A származtatott osztály a bázisosztály védett tagjai közül csak a saját osztályába tartozó ob- 
jektumokat tudja elérni: 


class Buffer ( 
brotected: 
char a[128]; 
HM aa: 
j; 


class Linked buffer : public Buffer€/E ..."/); 


class Cyclic buffer : public Buffer ( 


47744 
void fiinked buffer" p) ( 
alol — 0; // rendben: Cyclic buffer saját védett tagját éri el 
b-2a[l0]J- 0;  // hiba: más típus védett tagját próbáltuk elérni 
J 


Ez megakadályozza az olyan hibákat, amelyek azáltal léphetnének fel, hogy az egyik szár- 
maztatott osztály összezavarja a másik származtatott osztály adatait. 


15.3.1.1. A védett tagok használata 


Az adatok elrejtésének egyszerű privát/nyilvános modellje jól szolgálja a konkrét típusokat 
(§10.39. De ha származtatott osztályokat használunk, akkor kétféle felhasználója lesz egy 
osztálynak: a származtatott osztályok és ,a nagyközönség". A műveleteket megvalósító ta- 
gok és barátok ezen felhasználók érdekében kezelik az objektumokat. A privát/nyilvános 


modell lehetővé teszi a megvalósítás és az általános felhasználás pontos megkülönbözteté- 
sét, de a származtatott osztályok megfelelő kezelését nem. 


A protected-ként deklarált tagokkal sokkal könnyebb visszaélni, mint a privátként beveze- 
tettekkel. Ezért a tagok védettként való megadása általában tervezési hiba. Ha jelentős 
mennyiségű adatot úgy helyezünk el egy közös osztályban, hogy az összes származtatott 
osztály használhatja azokat, az adatok sérülhetnek. Még rosszabb, hogy a védett tago- 
kat — csakúgy, mint a nyilvánosakat — nem könnyű átszervezni, mert nincs jó módszer az 
összes használat felderítésére; így a védett tagok megnehezítik a program módosítását. 


Szerencsére nem kell feltétlenül védett tagokat használni; az osztályokra a privát az alapér- 
telmezett hozzáférési kategória és általában ez a jobb választás. Az én tapasztalatom az, 
hogy az összes származtatott osztály által közvetlenül használható, jelentős mennyiségű 
adat közös osztályban való elhelyezése helyett mindig adódik más megoldás. 
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Jegyezzük meg, hogy ezek a kifogások nem érvényesek a védett tagfüggvényekre; 
a protected minősítővel remekül adhatunk meg a származtatott osztályokban használható 
műveleteket. A §12.4.2 pontbeli /val slider is példa erre. Ha ebben a példában a megvaló- 
sító osztály privát lett volna, a további öröklés lehetetlenné vált volna. A tagok elérhetősé- 


gére példákat a §C.11.1 tartalmaz. 


15.3.2. Bázisosztályok elérése 
A tagokhoz hasonlóan egy bázisosztály is lehet nyilvános, védett vagy privát: 


class X : public Bf / ...?/); 
class Y : protected Bf /£ ...§/); 
class Z : private Bf / ..."/ 3; 


A nyilvános öröklés a származtatott osztályt a bázisosztály egy altípusává (subtype) teszi; ez 
az öröklés legáltalánosabb formája. A védett és a privát öröklés a megvalósítás módjának je- 
lölésére használatos. A védett öröklés olyan osztályhierarchiákban a leghasznosabb, ahol jel- 
lemzően további öröklés történik (a §12.4.2 pontbeli /val sliderjó példa erre). A privát bázis- 
osztályok akkor a leghasznosabbak, amikor egy osztályt a felület korlátozásával határozunk 
meg, ami által erősebb garanciák adhatók. A mutatókra vonatkozó Vector például érték-el- 
lenőrzéssel bővíti ki Vectorgvoid": bázisosztályát (413.5). Ha azt is biztosítani szeretnénk, 
hogy a Vec-hez (§3.7.2) való minden hozzáférés ellenőrzött legyen, bázisosztályát privátként 
kell megadnunk, így a Vec-ek nem konvertálódnak nem ellenőrzött vector-rá: 


template cclass T - class Vec : private Vector 2T2£/? ...?/ ); 


Az osztály hozzáférési szintjét nem muszáj explicit megadni. Ilyenkor az alapértelmezett 
hozzáférése class esetén privát, struct esetén nyilvános lesz: 


class XX: Bf. ..."/]); //B privát bázisosztály 
structYY: Bf, ..."/9; / B nyilvános bázisosztály 


Az olvashatóság szempontjából azonban legjobb kiírni a hozzáférési szintet megadó kulcsszót. 


A bázisosztály hozzáférési szintje az osztály tagjainak elérhetősége mellett a származtatott 
osztályra hivatkozó mutatóknak vagy referenciáknak a bázisosztály típusára való konvertál- 
hatóságát is jelzi. Vegyünk egy B bázisosztályból származó D osztályt: 


46 Ha B privát bázisosztály, akkor nyilvános és védett tagjai csak D tagfüggvényeiből 
és barátaiból érhetők el. Csak D barátai és tagjai konvertálhatnak egy D" mutatót 
B"-gá. 
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6 Ha B védett bázisosztály, akkor nyilvános és védett tagjai csak D tagfüggvényeiből 
és barátaiból, valamint a D-ből származó osztályok tagfüggvényeiből és barátaiból 
érhetők el. Csak D tagfüggvényei és barátai, valamint a D-ből származó osztályok 
tagfüggvényei és barátai végezhetnek konverziót Dt-ról B"-ra. 

4 Ha B nyilvános bázisosztály, nyilvános tagjai bárhol használhatók. Ezenkívül védett 
tagjai D tagfüggvényeiből és barátaiból, valamint a D-ből származó osztályok tagfügg- 
vényeiből és barátaiból érhetők el. Bármely függvény végezhet D"-ról B"-ra való 
konverziót. 


Ez alapvetően azonos a tagok elérhetőségi szabályaival (415.3). A bázisosztályok elérhető- 
ségét ugyanazon szempontok szerint adjuk meg, mint a tagokét. A BBwindow-t például 
azért adtam meg az I/val slider védett bázisosztályaként (412.4.2), mert a BBwindow inkább 
az Ival slider megvalósításának, mint felületének része. A BBwindow-t azonban nem rejt- 
hettem el teljesen úgy, hogy privát bázisosztállyá teszem, mert az I/val slider-ből további 
osztályokat akartam származtatni és azoknak el kellett érniük a megvalósítást. 


A bázisosztályok elérhetőségére a §C.11.2 mutat példákat. 


15.3.2.1. A többszörös öröklődés és az elérhetőség 


Ha egy nevet vagy bázisosztályt egy többszörös öröklődési háló több útvonalán is elérhe- 
tünk, akkor abban az esetben lesz elérhető, ha valamelyik út mentén elérhető: 


struct Bf 
int m; 
static int sm; 
VAKEN 

J; 


class D1 : public virtual Bf / ..."/) ; 
class D2 : public virtual Bf / ..."/) ; 
class DD : public DI, private D2( /? ..."/ 3; 


DD" pd - new DD; 
Bt pb - pd; // rendben: elérhető D1-en keresztül 
int il - pd-2m; // rendben: elérhető D1-en keresztül 


Ha egy bizonyos elemet több út mentén is elérhetünk, attól még egyértelműen, azaz töb- 
bértelműségi hiba nélkül hivatkozhatunk rá: 


class X1 : public Bf / ..."/) ; 
class X2 : public Bf / ..."/) ; 
class XX : public XI, public X2f€/F ..."/ 3; 
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XX" pxx - new XX; 
int il - pxx-2m; // hiba, többértelmű: XX::X1::B::m vagy XX::X2::B::m 
int i2 - pxx-2sm, // rendben: csak egy B::sm van egy XX-ben 


15.3.2.2. A using deklarációk és az elérhetőség 


A using deklarációk nem szolgálhatnak több információ elérésére, csak az egyébként is 
hozzáférhető adatok kényelmesebb használatát teszik lehetővé. Másrészt viszont, ha egy in- 
formáció elérhető, akkor a hozzáférési jog más felhasználók felé továbbadható: 


class Bf 
brivate: 

int a; 
brotected: 

int b; 
bublic: 

int c; 
3; 
class D : public B ( 
bublic: 

using B::a; . // hiba: B::a privát 

using B::b; . // B::b nyilvánosan elérhető D-n keresztül 


Ha egy using deklaráció privát vagy védett öröklődéssel jár együtt, akkor a bázisosztály ál- 
tal rendesen felkínált szolgáltatások egy részéhez felületet adhat: 


class BB : private B f // hozzáférést ad a B::b és B::c nevekhez, de a B::a-hoz nem 
bublic: 

using B::b; 

using B::c; 


J; 


Lásd még a §15.2.2 pontot. 
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15.4. Futási idejű típusinformáció 


A §12.4 pontban leírt /val box-ok valószerű használata lenne, ha átadnánk azokat egy kép- 
ernyőkezelő rendszernek, majd az visszaadná őket a programnak, valahányszor valamilyen 
tevékenység történt. Sok felhasználói felület működik így. Egy felhasználói felületet kezelő 
rendszer azonban nem feltétlenül tud a mi /val box-ainkról. A rendszer felületét a rendszer 
saját osztályai és objektumai nyelvén adják meg, nem a mi alkalmazásunk osztályainak 
nyelvén. Ez szükségszerű és rendjén is való, de azzal a kellemetlen következménnyel jár, 


hogy információt vesztünk a rendszernek átadott és később nekünk visszaadott objektu- 
mok típusáról. 


Az , elveszett" adatok visszanyeréséhez valahogy meg kell tudnunk kérdezni az objektum- 
tól a típusát. Bármilyen műveletet akarunk is végezni az objektummal, alkalmas típusú, az 
objektumra hivatkozó mutatóra vagy referenciára van szükségünk. Következésképpen egy 
objektum típusának futási időben való lekérdezéséhez a legnyilvánvalóbb és leghaszno- 
sabb művelet az, amely érvényes mutatót ad vissza, ha az objektum a várt típusú, illetve 
, nullpointert", ha nem. Pontosan ezt teszi a dynamic cast operátor. Például tegyük fel, 
hogy a rendszer a my event handlerO-t arra a BBwindow-ra hivatkozó mutatóval hívja 
meg, amellyel egy tevékenység történt. Ekkor az Ival box osztály do somethingO függvé- 
nyét használva meghívhatnánk programunkat: 


void my event handler(BBwindow?" pw) 


( 
if dval box? pb - dynamic castá£Ival box:r:(pw))  — // Vajon pw egy Ival box-ra mutat? 
bb-2do somethingO; 
else ( 
// hoppá! nem várt esemény 


J 
J 


A folyamatot úgy is magyarázhatjuk, hogy a dynamic cast fordít a felhasználói felületet ke- 
zelő rendszer sajátos nyelvéről az alkalmazás nyelvére. Fontos észrevenni, hogy mi nem 
nyert említést ebben a példában: az objektum tényleges típusa. Az objektum az Ival box 
egy bizonyos fajtája lesz, mondjuk /val slider, amelyet a BBwindow egy bizonyos típusa va- 
lósít meg, mondjuk a BBsSlider. Az objektum tényleges típusának kiderítése és megemlítése 
se nem szükséges, se nem kívánatos a rendszer és a program közötti ezen párbeszédben. 
Létezik felület a párbeszéd lényegének leírására, egy jól megtervezett felület pedig elrejti 
a lényegtelen részleteket. 
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Rajzban a 
bb - dynamic castáIval box?" (pw) 


utasítás hatását így ábrázolhatjuk: 


BBsSlider Ival slider 


BB ival slider 


A pw-ből és pb-ből kiinduló nyilak az átadott objektumra hivatkozó mutatókat jelölik, míg 
a többi nyíl az átadott objektum különböző részei közötti öröklődési viszonyokat ábrázolja. 


A típusinformációk futási időben való használatát hagyományosan futási idejű típusinfor- 
mációnak (run-time type information) hívják és gyakran R77I-nek rövidítik. 


A bázisosztályról származtatott osztályra történő konverziót gyakran , lefelé történő vagy 
származtatott irányú konverziónak" (downcasD hívják, mert az öröklési fák a hagyományos 
ábrázolás szerint a gyökértől , lefelé nőnek". Ehhez hasonlóan a származtatott osztályról 
bázisosztályra történő konverzió neve , felfelé történő konverzió", vagy ,bázisirányú kon- 
verzió" (upcasD. A bázisosztályról testvérre — például BBwindow-ról Ival box-ra — való 
konverziót , keresztbe történő konverziónak" (crosscasb) hívják. 


15.4.1. Dynamic cast 


A dynamic. cast (dinamikus típuskényszerítés) operátor két paramétert vár, egy 2 közé írt 
típust és egy O közé írt mutatót vagy referenciát. 


Vegyük először a mutató esetét: 


dynamic casi£T?"rx(p) 
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Ha a pa T" típusba, vagy olyan D " típusba tartozik, ahol 7bázisosztálya D-nek, akkor az 
eredmény ugyanaz, mintha a b-t egy T" változónak adtuk volna értékül: 


class BB ival slider : public Ival slider, protected BBslider f 


4 aa 
j; 
void BB ival slider" p) 
t 
Ival slider" pi1 - p; // rendben 
Ival slider" pi2 - dynamic castíIval slider x(p; // rendben 
BBsSlider" pbb1 - p; // hiba: BB$Slider védett bázisosztály 
BBslider" pbb2 - dynamic castZBBslider" (p9; // rendben: pbb2 értéke O lesz 
J 


Ez nem túl érdekes. Azt azonban jó tudni, hogy a dynamic cast nem engedi meg a védett 
vagy privát bázisosztályok védelmének véletlen megsértését. 


A dynamic cast célja azon esetek kezelése, amelyeknél a fordítóprogram nem tudja a 
konverzió helyességét megítélni: 


dynamic casi£T?tx(p) 


A fenti kód megvizsgálja a p által mutatott objektumot (ha van ilyen). Ha az objektum Tosz- 
tályú vagy van egy egyértelmű 7 típusú őse, akkor a dynamic cast egy, az objektumra hivat- 
kozó T" típusú mutatót ad vissza, más esetben 0-át. Ha p értéke 0, a dynamic castSKT?"rx(p) 
eredménye O lesz. Jegyezzük meg, hogy a konverzió csak egyértelműen azonosított objektu- 
moknál működik. Lehet olyan példákat hozni, ahol a konverzió nem sikerül és 0-át ad, mert 
a p által mutatott objektumnak több 7 típusú bázisosztályt képviselő részobjektuma van 


(415.4.2). 


A dynamic. cast-nak a lefelé vagy keresztbe történő konvertáláshoz többalakú (polimorfP) 
mutatóra vagy hivatkozásra van szüksége: 


class My slider: public Ival sliderf // többalakú bázisosztály (Tval slider rendelkezik 
// virtuális függvényekkel) 


VMSZ 
j; 
class My date : public Date f / nem többalakú bázisosztály (Date nem rendelkezik 
// virtuális függvényekkel) 
Vé 


74 


538 Absztrakciós módszerek 


void g(dval box? pb, Date? pd) 


( 
My slidert pd1 - dynamic castSMy slidertrx(pb); — / rendben 


My date: pd2 - dynamic castcMy datet:(pd); // hiba: Date nem többalakú 


J 


Az a megkötés, hogy a mutatónak többalakúnak kell lennie, egyszerűsíti a dyvnamic cast 
megvalósítását, mert megkönnyíti az objektum típusának tárolásához szükséges információ 
helyének megtalálását. Általános megoldás, hogy a típust jelző mutatót az objektum virtuá- 
lis függvénytáblájába (42.5.5) helyezik, ezáltal egy , típus-információ objektumot" fűznek az 
objektumhoz: 


My slider: 





type info: 





type info: 


"My slider" 
bázisosztályok Jé "val slider" 






































A szaggatott nyíl az eltolást Coffset) jelöli, amelynek segítségével a teljes objektum kezdete 
megtalálható, ha csak egy többalakú részobjektumra hivatkozó mutató adott. Világos, hogy 
a dynamic cast hatékonyan felhasználható; csak néhány, a bázisosztályt leíró tybe info ob- 
jektumot kell összehasonlítani, nincs szükség hosszadalmas keresésre vagy karakterláncok 
összehasonlítására. 


A dynamic. cast-nak többalakú típusokra való korlátozása logikai szempontból nézve is ér- 
telmes. Ha egy objektumnak nincs virtuális függvénye, akkor pontos típusának ismerete 
nélkül nem kezelhető biztonságosan, ezért ügyelni kell, hogy az ilyen objektum ne kerül- 
jön olyan környezetbe, ahol nem ismeretes a pontos típusa. Ha azonban a típusa ismert, 
nincs szükség dynamic cast-ra. 


A dynamic cast céltípusa nem kell, hogy többalakú legyen, ezért egy konkrét típust több- 
alakúba csomagolhatunk, mondjuk, hogy egy objektumokat kezelő ki- és bemeneti rend- 


szeren keresztül továbbítsuk (425.4.1), majd később kicsomagoljuk belőle a konkrét típust: 
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class Io obj( // bázisosztály-objektum az I/O rendszer számára 
virtual Io obj" clone0 — 0; 


j; 
class Io date : public Date, public Io obj ( ?); 


void fdo obj" pio) 


t 
Date? pd - dynamic castéDate? x(pioJ; 
Méz 


Egy többalakú objektum kezdőcímét egy void"-ra való dinamikus típuskényszerítéssel ha- 
tározhatjuk meg: 


void g(dval box? pb, Date" pd) 


( 
voidt pd1 - dynamic castKvoidt (pb); // rendben 
void" pd2 - dynamic castíZvoid" x(pd); // hiba: Date nem többalakú 


J 


Ez azonban csak nagyon alacsony szintű függvényekkel való együttműködés céljára hasznos. 


15.4.1.1. Referenciák dinamikus típuskényszerítése 


Egy objektum többalakú (polymorpb) viselkedéséhez akkor férünk hozzá, ha mutatón 
vagy referencián át kezeljük. A dynamic cast művelet sikertelenségét 0-val jelzi. Ez 
referenciákra se nem kivitelezhető, se nem kívánatos. 


Ha egy mutatóról, mint eredményről van szó, akkor fel kell készülnünk arra a lehetőségre, 
hogy az eredmény 0 lesz, azaz a mutató nem mutat semmilyen objektumra. Ezért egy 
dynamic cast művelet eredményét mindig ellenőriznünk kell. A b mutatón végzett 
dynamic cast£T" (p) egy kérdésként fogható fel: ,a b által mutatott objektum 7típusú?" 


Másrészt viszont jogosan tételezhetjük fel, hogy egy referencia mindig egy objektumra vo- 
natkozik. Következésképpen egy r referencia esetén a dynamic casi£ZI£:(r) nem kérdés, 
hanem állítás: ,a ráltal mutatott objektum 7típusú." A dynamic cast művelet eredményét 
maga a dynamic cast-ot megvalósító kód ellenőrzi automatikusan, és ha a dynamic cast 
operandusa nem a várt típusú hivatkozás, akkor bad cast kivételt vált ki: 
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void fdval box? p, Ival box r) 
( 
if dval slider" is - dynamic castXIval slider" (p)) f / Vajon p egy Ival slider-re mutat? 
// "is" használata 


J 


else ( 
/?p nem slider 
) 
Ival sliderg is - dynamic castXIval sliderőz (Tr; // az r egy Ival  slider-re hivatkozik! 
// "is" használata 


j 


A sikertelen dinamikus mutató- illetve referencia-átalakítások eredményének eltérésében 
a mutatók, illetve a referenciák közötti alapvető különbség tükröződik. Ha egy felhasználó 


védekezni akar a referencia-átalakítás sikertelensége ellen, akkor egy megfelelő kivételke- 
zelőre van szüksége: 


void gO 
( 
try ( 
Knew BB ival slider, new BB ival slider); — // a paraméterek Ival box-ként 
// adódnak át 
KkKnew BBdial new BBdiaD; // a paraméterek Ival box-ként adódnak át 
2 
J 
catch (bad cast) ( // §14.10 


1/8720 


j 


j 
Az fO függvény első meghívása sikeresen fog visszatérni, míg a második bad cast kivételt 
vált ki, amit g0 elkap. 


A 0 érték ellenőrzése elhagyható, így alkalmasint véletlenül el is fog maradni. Ha ez ag- 
gasztja az olvasót, akkor írhat egy olyan konverziós függvényt, amely sikertelenség esetén 
a O érték visszaadása helyett kivételt vált ki (415.8[1]. 


15.4.2. Osztályhierarchiák bejárása 


Ha csak egyszeres öröklődést használunk, az osztály és bázisosztályai egyetlen bázisosz- 
tályban gyökerező fát alkotnak. Ez egyszerű, de gyakran túl erős megszorítást jelent. Több- 
szörös öröklődés használata esetén nincs egyetlen gyökér. Ez önmagában nem bonyolítja 
nagyon a helyzetet, de ha egy osztály többször fordul elő a hierarchiában, akkor némi óva- 
tossággal kell az adott osztályú objektumra vagy objektumokra hivatkoznunk. 
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Természetesen a hierarchiákat igyekszünk annyira egyszerűnek venni — de nem egysze- 
rűbbnek -, amennyire programunk megengedi. De ha már kialakult egy bonyolultabb hie- 
rarchia, hamarosan szükségünk lesz annak bejárására (vagyis végignézésére), hogy alkal- 
mas osztályt találjunk, amelyet felületként használhatunk. Ez az igény két esetben merülhet 
fel. Néha kifejezetten meg akarunk nevezni egy bázisosztályt vagy annak egy tagját (példá- 
ul §15.2.3 és §15.2.4.19. Máskor egy, a bázisosztályt vagy annak egy származtatott osztályát 
megjelenítő objektumra hivatkozó mutatóra van szükségünk, ha adott egy mutató a teljes 
objektumra vagy annak valamely részobjektumára (415.4 és §15.4.1)9. 


Itt azt tekintjük át, hogyan lehet típuskényszerítést (casD) használva a kívánt típusú mutató- 
hoz jutni. Hogy szemléltessük az elérhető módszereket és a rájuk vonatkozó szabályokat, 
vegyünk egy többször szereplő és virtuális bázisosztályt egyaránt tartalmazó hálót: 


class Component : public virtual Storable f /£ ...§/); 

class Receiver : public Component f /£ ... t/); 

class Transmitter : public Component f /£ ... §/); 

class Radio : public Receiver, public Transmitter £ /£ ... "/ ); 


Ábrával: 


Storable 


Eza dlálüa S 


Component Component 


1 


Receiver TIransmitter 


TESSgge szék 


Radio 


Itt a Radio objektumnak két Component osztályú részobjektuma van. Ezért a Radio-n belü- 
li, Storable-ról Component-re való dinamikus típuskényszerítés többértelmű lesz és nullát 
ad. Ilyenkor egyszerűen nem lehet tudni, melyik Component-re gondolt a programozó: 


void hI(Radiokg r) 
( 
Storable? ps - £r; 
ze 
Componentt pc - dynamic castkComponentt (ps); /pc- 0 
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Ez a többértelműség fordítási időben általában nem deríthető fel: 


void hX(Storable? ps) // ps-ről nem tudjuk, hogy Component-re mutat-e 
( 


Component" pc - dynamic castkKComponent" (ps); 


Mi 


j 
A többértelműségnek ez a fajta felderítése csak virtuális bázisosztályoknál szükséges. Kö- 
zönséges bázisosztályok és lefelé (azaz a származtatott osztály felé történő; §15.4 
konverzió esetén a kívánt típusú részobjektum mindig egyértelmű (ha létezik). Ezzel 
egyenértékű többértelműség lép fel felfelé (azaz a bázisosztály felé történő) konverzió ese- 
tén és ezek a többértelműségek fordítási időben kiderülnek. 


15.4.2.1. Statikus és dinamikus konverzió 


A dynamic cast művelet többalakú bázisosztályról származtatott osztályra vagy testvérosz- 
tályra való átalakítást tud végezni (§15.4.1). A static cast (§6.2.7) nem vizsgálja a kiinduló 
objektum típusát, így nem képes ezekre: 


void g(kadiok r) 
( 


Receiver? prec - £r; // a Receiver a Radio közönséges bázisosztálya 
Radio? pr - static castZRadio" x(prec); // rendben, nincs ellenőrzés 
br - dynamic castZRadio? x(prec); // rendben, futási idejű ellenőrzés 


Storable? ps - £r; // a Storable a Radio virtuális bázisosztálya 
br static castéRadiotx(p9), — // hiba: virtuális bázisosztályról nem lehet átalakítani 
br - dynamic castZRadio? x(p5); // rendben, futási idejű ellenőrzés 


A dynamic. cast-nak többalakú operandusra van szüksége, mert egy nem többalakú objek- 
tum nem tárol olyan információt, amelynek alapján meg lehetne keresni azon objektumo- 
kat, amelyeknek őse (bázisa). Olyan objektum is lehet például virtuális bázisosztály, amely- 
nek a memóriában való elhelyezkedését egy másik nyelv, például a Fortran vagy a C hatá- 
rozza meg. Ezekre vonatkozóan csak statikus adatok állnak rendelkezésre, de 
a dynamic cast megvalósításához szükséges információt a futási idejű típusinformáció tar- 
talmazza. 


Miért akarna valaki static cast-ot használni egy  osztályhierarchia bejárására? 
A dynamic cast némileg növeli a futási időt (415.4.1), de ennél jelentősebb ok, hogy millió 
sornyi kód van a dynamic cast bevezetése előtti időkből. Az ilyen kódok más módokon 
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biztosítják az alkalmazott típusátalakítások helyességét, így a dyvnamic cast-tal végeztetett 
ellenőrzés feleslegesnek tűnik. Az ilyen — általában C stílusú típuskonverzióval (46.2.7) író- 
dott — kódban azonban gyakran maradhatnak rejtett hibák, így, hacsak lehet, használjuk 
a biztonságosabb dynamic cast-ot. 


A fordítóprogram nem tételezhet fel semmit egy void?" mutató által mutatott memóriaterü- 
letről. Ebből következik, hogy az objektum típusa felől érdeklődő dynamic cast nem ké- 
pes void"-ról konvertálni. Ehhez static cast kell: 


Radio?" f(void? p) 
í 


Storable?t ps - static castcStorablet x(p); // Bízzunk a programozóban! 
return dynamic cast£ZRadio? 2(p5); 


J 


Mind a dynamic cast, mind a static cast tiszteletben tartja a const minősítést és a hozzáfé- 
rési korlátozásokat: 


class Users : private setkPerson: f /£ ...§/); 


void (Users? pu, const Receiver? pcr) 


( 
static castssetéPerson:t (pu); // hiba: nem férhet hozzá 
dynamic castsset£Person:? x(puJ; // hiba: nem férhet hozzá 
static castZReceiver" x(pcr); // hiba: const minősítés nem vész el 
dynamic cast£Receiver? x(pcr); // hiba: const minősítés nem vész el 
Receiver" pr - const cast£Receiver? x(pcr); // rendben 
1 as 

J 


Privát bázisosztályra nem lehet konvertálni, const-ot nem konstanssá konvertálni pedig 
csak const cast-tal lehet (46.2.7), és még akkor is csak úgy kapunk helyes eredményt, ha az 
objektumot eredetileg nem const-ként deklaráltuk (410.2.7.1. 


15.4.3. Osztályobjektumok felépítése és megsemmisítése 


Egy valamilyen osztályba tartozó objektum több, mint egyszerűen a memória egy része 
(§4.9.609. Az osztályobjektumokat konstruktoraik építik fel a ,nyers memóriából" és 


destruktoraik lefutásával válnak újra , nyers memóriává". Az objektum felépítése alulról fel- 
felé, megsemmisítése felülről lefelé történik, és az osztályobjektum olyan mértékben létező 
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objektum, amennyire felépítése, illetve megsemmisítése megtörtént. Ez tükröződik a futási 
idejű típusazonosításra (RTTD, a kivételkezelésre (§14.4.7) és a virtuális függvényekre vo- 
natkozó szabályokban. 


Nem bölcs dolog az objektumfelépítés vagy -megsemmisítés sorrendjére támaszkodni, de 
a sorrendet megfigyelhetjük, ha virtuális függvényeket, dynamic cast-ot vagy tybeid-t 
(415.4.4) hívunk akkor, amikor az objektum még nincs készen. Például ha a §15.4.2 pont- 
beli hierarchia Combonent konstruktora egy virtuális függvényt hív, akkor a Sztorable vagy 
Component-beli változatot fogja meghívni, nem a Receiver, Transmitter vagy Radio-belit. 
Az objektum létrehozásának ezen pontján az objektum még nem Radio; csak egy részben 
felépített objektum. Ennek fényében legjobb elkerülni a virtuális függvényeknek 
konstruktorból vagy destruktorból való meghívását. 


15.4.4. Typeid és kiterjesztett típusinformáció 


A dynamic cast operátor az objektumok típusára vonatkozó, futási időben jelentkező in- 
formációigény legnagyobb részét kielégíti. Fontos tulajdonsága, hogy biztosítja a felhaszná- 
ló kód helyes működését a programozó által használt osztályokból származó osztályokkal 
is. Így a dvnamic casta virtuális függvényekhez hasonlóan megőrzi a rugalmasságot és bő- 
víthetőséget. 


Néha azonban alapvető fontosságú tudni az objektum pontos típusát. Például tudni szeret- 
nénk az objektum osztályának nevét vagy memóriakiosztását. A typeid operátor ezt az 
operandusa típusát jelző objektum visszaadásával támogatja. Ha a typeidO függvény lenne, 
valahogy így adhatnánk meg: 


class type info; 
const type infok typeid(tybe name) throwO; // ál-deklaráció 
const type infog typeid(expression) throw(bad typeid); // ál-deklaráció 


Azaz a typeidO egy standard könyvtárbeli, a Ctybeinfo: fejállományban definiált tybe info 
nevű típusra való referenciát ad vissza. Ha operandusként egy típusnevet kap, a tybeidO az 
azt ábrázoló type info-ra való referenciával tér vissza, ha kifejezést, a kifejezés által jelölt 
objektumot ábrázoló type info-ra fog hivatkozni. A tybeidO leginkább egy referenciával 
vagy mutatóval jelölt objektum típusának lekérdezésére használatos: 


void KShapek r, Shape" p) 
typeid(r9; // az r által hivatkozott objektum típusa 


typeidCp9; // a p által mutatott objektum típusa 
typeid(p9; // a mutató típusa, vagyis Shape" (nem gyakori, leginkább tévedés) 
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Ha a mutató vagy referencia operandus értéke O, a typeidO bad typeid kivételt vált ki. 
A type info megvalósítás-független része így néz ki: 


class type info ( 


bublic: 
virtual -type infoO; // többalakú 
bool operator——(const type infok) const; // összehasonlítható 
bool operator!/-(const type infok) const; 
bool before(const type infok) const; // rendezés 
const char: nameO const; // a típus neve 
Private: 
type info(rconst type infok ); // másolás megakadályozása 
type infok operator—(const type infok); // másolás megakadályozása 
VAY 
j; 


A beforeO függvény lehetővé teszi a tybe info objektumok rendezését. A meghatározott 
rendezési sorrendnek nincs köze az öröklési viszonyokhoz. 


Nem biztos, hogy a rendszer minden egyes típusát egyetlen tybe info objektum képviseli. 
Dinamikus csatolású könyvtárak használata esetén például valóban nehéz a több type info 
objektumot elkerülő megvalósítás elkészítése. Ezért a —-— művelettel az egyenlőséget 
a type info objektumok és nem az azokra hivatkozó mutatók esetében vizsgáljuk. 


Néha tudni akarjuk egy objektum pontos típusát, hogy valamilyen szabványos műveletet 
végezzünk az egész objektumon (és nem csak annak egy ősén). Ideális esetben az ilyen 
műveletek virtuális függvények formájában állnak rendelkezésre, így nem szükséges a pon- 
tos típus ismerete. Egyes esetekben azonban nem tételezhető minden egyes kezelt objek- 
tumra vonatkozó közös felület, így a megoldás útja a pontos típuson keresztül vezet 
(415.4.4.19. Egy másik, sokkal egyszerűbb használat az osztály nevének diagnosztikai kime- 
net céljára való lekérdezése: 


iincludeztypeinfo:z 


void ((Component" p) 
( 


J 


cout cz typeidCp).nameO; 
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Az osztályok nevének szöveges ábrázolása az adott nyelvi változattól függ. C stílusú karak- 
terláncokkal történik, amelyek a rendszerhez tartozó memóriarészben vannak, ezért ne 
próbáljuk meg a deletel / műveletet alkalmazni rájuk. 


15.4.4.1. Kiterjesztett típusinformáció 


Egy objektum pontos típusának meghatározása általában csak az első lépés a rá vonatkozó 
részletesebb információk megszerzése és használata felé. 


Gondoljuk meg, hogy egy program vagy programozást segítő eszköz hogyan tudna futási 
időben típusokról szóló információt adni a felhasználóknak. Tegyük fel, hogy van egy esz- 
közünk, amely minden felhasznált osztályról megmondja az objektum memóriakiosztását. 
Ezeket a leírókat egy map-be tehetem, hogy annak alapján a felhasználói kód megtalálhas- 
sa a memóriakiosztási információt: 


mapsstring, Layout: layout table; 


void (B p) 

( 
Layoutk x - layout tableltypeidCp).nameO[; 
// x használata 


Valaki más egészen eltérő információt adhat: 


struct TI eg f 
bool operatorO(const type info? p, const type info? a) f return ?p--t g; ) 


J; 


struct TI hash ( 





int operator (const type infot p); // hasítóérték kiszámítása (§17.6.2.2) 
3 
hash mapcconst type infot Icon,hash fct,TI hash,TI eg: icon table; // §17.6 
void (B? p) 


t 
Iconkg i - icon tablelktypeidCp)l; 
// i használata 
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A typeid-ekhez információ rendelésének ez a módja több programozó vagy eszköz számára 
teszi lehetővé, hogy a típusokhoz egymástól teljesen független információkat rendeljenek: 





layout table: 





s] Az objektum 
memóriakiosztása 














icon table: ő ; 
S E Ze ge zezeáezk EBET 9] A típus ikonos 


NENREETSZÉ ábrázolása 











k typeidC 7 

















Ez nagyon fontos, mert annak valószínűsége, hogy valaki információknak olyan halmazával 
tud előállni, amely egymagában minden felhasználó igényeit kielégíti, a nullával egyenlő. 


15.4.5. Az RTTI helyes és helytelen használata 


Csak szükség esetén használjunk explicit futási idejű típusinformációt. A statikus (fordítási 
időben történő) ellenőrzés biztonságosabb, , olcsóbb" és — alkalmasint — jobban szerkesz- 
tett programokhoz vezet. A futási idejű típusinformációt például arra használhatjuk, hogy 


egy rosszul álcázott switch utasítást írjunk: 


// a futási idejű típusinformáció helytelen használata 
void rotate(const Shapek r) 


if (ypeid(r) -- typeid(Circle)) f 
// nem csinálunk semmit 


j 
else if (typeid(r) -—- typeid(1riangle)) f 
// háromszög forgatása 


j 

else if (typeid(r) -- typeid(Sguare)) f 
// négyzet forgatása 

j 

V/ARYO 


A dynamic cast-nak a typeid helyett való használata alig javítana ezen a kódon. 
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Sajnos ez nem egy légből kapott példa; ilyen kódot tényleg írnak. A C-hez, a Pascalhoz, 
a Modula-2-höz, vagy az Adához hasonló nyelveken nevelkedett programozó majdnem el- 
lenállhatatlan kísértést érez, hogy a programot switch utasítások halmazaként építse fel. En- 
nek a kísértésnek általában ellen kell állni. Futási idejű típusazonosítás helyett inkább vir- 
tuális függvényeket (42.5.5, §12.2.609) használjunk a legtöbb olyan eset kezelésére, amikor 
a típuson alapuló futási idejű megkülönböztetés szükséges. 


Az RTTI helyes használata sokszor merül fel akkor, amikor a kódban valamilyen szolgálta- 
tást egy bizonyos osztályhoz kapcsolunk és a felhasználó öröklődéssel akar további szol- 
gáltatásokat hozzáadni. A §15.4 pontbeli Ival box használata ennek egy példája. Ha a fel- 
használó hajlandó és képes a könyvtári osztályok — például a BBwindow — módosítására, 
akkor az RTTI használata elkerülhető; különben viszont szükséges. De ha a felhasználó haj- 
landó is a könyvtári osztályok módosítására, az ilyen módosítás problémákhoz vezethet. 
Például szükségessé válhat a virtuális függvények ál-megvalósítása olyan osztályok eseté- 
ben, amelyeknél azok nem szükségesek vagy nem értelmesek. Ezt a problémát a §24.4.3 né- 
mileg részletesebben tárgyalja. Az RTTI-nek egy egyszerű, objektumokat kezelő ki- és be- 
meneti rendszer elkészítésére szolgáló használatát a §425.4.1 írja le. 


Azok számára, akik a Smalltalkon vagy a Lispen, esetleg más, nagymértékben a dinamikus 
típusellenőrzésre építő nyelveken nevelkedtek, csábító dolog az RTTI-t túlságosan általá- 
nos típusokkal együtt használni. Vegyük ezt a példát: 


// a futási idejű típusinformáció helytelen használata 
class Object £ /§ ... 7); /többalakú 


class Container : public Object f 
bublic: 

void put(Object" ); 

Object" get; 

41 e 


J; 


class Ship : public Object f/£ ..."/); 


Ship? (Ship? ps, Container? c) 
( 


c-2put(p5); 

27 as 

Object" p - c-3getO; 

if (Ship: g - dynamic castcShipt x(p)) ( // fatási idejű ellenőrzés 


return d; 


J 
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else ( 
// valami mást csinálunk (általában hibakezelést végzünk) 


J 
J 


Itt az Object osztály szükségtelen és mesterkélt. Túlságosan általános, mert az adott alkalma- 
zásban nem felel meg semmilyen elvonatkoztatási szintnek és a programozót egy megvaló- 
sítás-szintű fogalom használatára kényszeríti. Az ilyen jellegű problémákat gyakran jobban 
oldja meg, ha kizárólag egy adott típusú mutatót tartalmazó tároló sablonokat használunk: 


Shipt fCShip" ps, listcShipt:£ c) 
( 


c.push front(p59; 
1171 
return c.bop frontO; 


Virtuális függvényekkel együtt használva így majdnem minden esetet megoldhatunk. 


15.5. Tagra hivatkozó mutatók 


Sok osztálynak van egyszerű, nagyon általános felülete, amelyet sokféle használatra szán- 
tak. Például sok , objektumorientált" felhasználói felület határoz meg egy sor kérést, amely- 
re minden, a képernyőn megjelenített objektumnak tudnia kell válaszolni. Ráadásul az ilyen 
kérések közvetett vagy közvetlen módon programoktól érkezhetnek. Vegyük ezen elv egy 
egyszerű változatát: 


class Std interface ( 

public: 
virtual void startÖ) — O; 
virtual void susbendO - 0; 
virtual void resume — 0; 
virtual void gutitÓ - 0; 
virtual void full size0 - 0; 
virtual void smallÓ — 0; 


virtual -Std interfaceO () 


550 Absztrakciós módszerek 


Minden művelet pontos jelentését az az objektum definiálja, amelyre alkalmazzák. Gyakran 
a kérést kiadó személy vagy program és a fogadó objektum között egy szoftverréteg van. 
Ideális esetben az ilyen köztes rétegeknek nem kell semmit tudniuk az egyes műveletekről 
(resumeO, full sizeO stb.). Ha tudnának, a köztes rétegeket fel kellene újítani, valahány- 
szor a műveletek halmaza megváltozik. Következésképpen az ilyen köztes rétegek csupán 
továbbítanak valamely, az alkalmazandó műveletre vonatkozó adatot a kérés forrásától 
a fogadóhoz. 


Ennek egyszerű módja az alkalmazandó műveletet jelölő karakterlánc küldése. Például 
a suspendO meghívása céljából a , suspend" (felfüggesztés) szöveget küldhetnénk. Valaki- 
nek azonban létre kell hoznia a karakterláncot, valakinek pedig meg kell fejtenie, melyik 
művelethez tartozik, ha egyáltalán tartozik valamelyikhez. Ez gyakran túlságosan közvetett- 
nek és fáradságosnak tűnik. Ehelyett küldhetnénk csak egy, a műveletet jelölő egész érté- 
ket. Mondjuk a 2 jelenthetné a suspend-et. De amíg egy egész számot a számítógépek ké- 
nyelmesen kezelnek, az emberek számára ez meglehetősen zavaró lehet, ráadásul még 
mindig meg kell írnunk a kódot, amely meghatározza, hogy a 2 a suspendO-et jelenti és 
meg kell hívnunk a suspendŐ-et. 

A C44 nyelv lehetővé teszi az osztályok tagjainak közvetett elérését. A tagra hivatkozó mu- 
tató olyan érték, amely az osztály egy tagját azonosítja. Gondolhatunk rá úgy, mint egy, az 
adott osztályhoz tartozó objektumban levő tag helyére, de a fordító természetesen figye- 
lembe veszi az adattagok, a virtuális és nem virtuális függvények stb. közötti különbséget. 


Vegyük az Sid interface-t. Ha meg akarjuk hívni a susbendO-et valamely objektumra anél- 
kül, hogy közvetlenül megneveznénk, akkor egy olyan mutatóra lesz szükségünk, ami az 
Sid interface::suspendO tagra mutat. Ugyancsak szükségünk lesz a suspendO révén felfüg- 
gesztendő objektumra hivatkozó mutatóra vagy referenciára. Vegyünk egy igen egyszerű 
példát: 

typedef void (Std. interface::" Pstd mem)O; // tagra hivatkozó mutató 

void ((Std interface? p) 

( 

Pstd mem s - £kStd interface::suspend; 


b-2suspendO; // közvetlen hívás 


(p-2t JO; // hívás tagra hivatkozó mutatón keresztül 
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Egy tagra hivatkozó mutatót (pointer to member) úgy kapunk, hogy a címképző £ operá- 
tort egy teljes nevű (, teljesen minősített", fully gualified) osztálytagra alkalmazzuk (például 
kSid interface::suspendO). Az ,X osztály egy tagjára hivatkozó mutató" típusú változókat 


az X::" formában deklarálhatjuk. 


A C szintaxis áttekinthetőségének hiányát általában a tybedef alkalmazásával ellensúlyozzák, 
az X::" forma viszont láthatóan nagyon szépen megfelel a hagyományos " deklarátornak. 


Egy m tagra hivatkozó mutatót egy objektummal kapcsolatban használhatunk. A kapcsola- 
tot a -2? és .F operátorokkal fejezhetjük ki. Például a D-2"m az m-et a p által mutatott objek- 
tumhoz köti, az obj."m pedig az obj objektumhoz. Az eredmény az m típusának megfele- 
lően használható, de a -2? vagy .?" művelet eredményét nem lehet későbbi használatra 
félretenni. 


Természetesen ha tudnánk, melyik tagot akarjuk meghívni, közvetlenül meghívnánk azt, 
a tagra hivatkozó mutatókkal való bajlódás helyett. A közönséges függvénymutatókhoz ha- 
sonlóan a tagfüggvényekre hivatkozó mutatókat akkor használjuk, amikor a tag nevének is- 
merete nélkül akarunk egy függvényre hivatkozni. A tagra hivatkozó mutató azonban nem 
egyszerűen egy mutató egy memóriaterületre, mint egy változó címe vagy egy függvény- 
mutató, inkább egy adatszerkezeten belüli eltolásra (offszetre) vagy egy tömbbeli indexre 
hasonlít. Amikor egy tagra hivatkozó mutatót a megfelelő típusú objektumra hivatkozó mu- 
tatóval párosítjuk, olyasvalami keletkezik, ami egy bizonyos objektum egy bizonyos tagját 
azonosítja. Ezt rajzzal így ábrázolhatjuk: 





vtbl.: 








I X::start 


st eggye] EE jáát X::suspend 
Mélszesztfet Y 



































Mivel egy virtuális tagra hivatkozó mutató (a fenti példában 5) egyfajta eltolás, nem függ az 
objektum helyétől a memóriában, ezért biztonságosan átadható egy másik címtérnek 
(address space), feltéve, hogy az objektum elhelyezkedése a kettőben azonos. A közönsé- 
ges függvényekre hivatkozó mutatókhoz hasonlóan a nem virtuális tagfüggvényekre hivat- 
kozó mutatókat sem lehet másik címtérnek átadni. 
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Jegyezzük meg, hogy a függvénymutatón keresztül meghívott függvény lehet virtuális is. 
Például amikor egy függvénymutatón keresztül meghívjuk a susbendO-et, akkor azon ob- 
jektum típusának megfelelő susbendO-et kapjuk, amelyre a függvénymutatót alkalmaztuk. 
Ez a függvénymutatóknak igen lényeges tulajdonsága. 


Egy tolmácsoló (továbbító, interpreter) függvény egy tagra hivatkozó mutató segítségével 
meghívhat egy karakterlánccal (vagyis szöveggel) megadott függvényt: 


mapsstring,Std interface: variable; 
mapsstring,Pstd mem: operation; 


void call membercstring var, string oper) 


( 


j 


(variablelvar]-2" operationloper]D O; // var.operÓ 


A tagfüggvényekre hivatkozó mutatók legfontosabb használatát a §3.8.5 és §18.4 pontbeli 
mem funO függvényben vizsgálhatjuk meg. 


A statikus tagok nem tartoznak egy bizonyos objektumhoz, így egy statikus tagra hivatko- 
zó mutató csupán egy közönséges mutató: 


class Task f 
47 ea 


static void scheduleO; 


J; 


void Cp)O - £Task::schedule; // rendben 
void (Task::" pm)O - £Task::schedule; // hiba: egyszerű mutatót adtunk értékül 
// tagra hivatkozó mutatónak 


Az adattagokra hivatkozó mutatókat a §C.12 pont írja le. 


15.5.1. Bázis- és származtatott osztályok 


Egy származtatott osztály legalább azokkal a tagokkal rendelkezik, amelyeket a bázisosz- 
tályból örököl, de gyakran többel. Ez azt jelenti, hogy egy bázisosztály egy tagjára hivatko- 
zó mutatót biztonságosan értékül adhatunk egy származtatott osztálytagra hivatkozó 
mutatónak, de fordítva nem. Ezt a tulajdonságot gyakran kontravarianciának 
(contravariance) hívják: 
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class text : public Std interface f 


bublic: 
void startO; 
void suspendO; 
FgES 
virtual void printO; 
brivate: 
vector S; 
Hz 
void (Std. interface::" bpmiO - £text::print; // hiba 
void (text:"pmDO - ksStd interface::start; // rendben 


A fel nem cserélhetőség ezen szabálya látszólag ellenkezik azzal a szabállyal, hogy egy szár- 
maztatott osztályra hivatkozó mutatót értékül adhatunk a bázisosztályára hivatkozó muta- 
tónak. Valójában azonban mindkét szabály azért van, hogy biztosítsa az alapvető garanciát 
arra, hogy egy mutató soha nem mutat olyan objektumra, amelynek nincsenek meg a mu- 
tató típusa által ígért tulajdonságai. Ebben az esetben az Szd interface::" bármilyen 
Std interface-re alkalmazható, és a legtöbb ilyen objektum vélhetőleg nem text típusú lesz. 
Ezért aztán nincs meg a text::brint tagjuk, amellyel bmi-nek kezdőértéket próbáltunk adni. 
A kezdeti értékadás megtagadásával a fordítóprogram egy futási idejű hibától ment meg 
bennünket. 


15.6. A szabad tár 


Az operator new és az operator deleteO definiálásával át lehet venni a memóriakezelést 
egy osztálytól (46.2.6.29. Ezen globális függvények kicserélése azonban nem a félénkeknek 
való, hiszen előfordulhat, hogy valaki az alapértelmezett viselkedésre számít vagy ezen 
függvények valamilyen más változatát már meg is írta. 


Gyakran jobb megközelítés ezeket a műveleteket egy bizonyos osztályra megírni. Ez az 
osztály több származtatott osztály alapja is lehet. Tegyük fel, hogy a §12.2.6-beli Employee 
osztályt és annak minden leszármazottját szeretnénk egyedi memóriafoglalóval (allokátor- 
ral) és -felszabadítóval (deallokátorral) ellátni: 


class Employee f 
Mesa 

bublic: 
4 
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void? operator new(size 1); 


void operator delete(void" , size 1; 


J; 


Az operator neug és az operator deleteO) tagfüggvények automatikusan statikusak lesznek, 
ezért nincs this mutatójuk és nem változtatnak meg egy objektumot, csak olyan tárterületet 
adnak, amelyet a konstruktorok feltölthetnek és a destruktorok kitakaríthatnak. 


void: Employee::operator neu(size t 5) 


( 


J 


// lefoglal s! bájtnyi memóriát és rá hivatkozó mutatót ad vissza 


void Employee::operator delete(void" p, size t 5) 


if (p) ( // törlés csak ha p!/-O; lásd §6.2.6, §6.2.6.2 
// feltesszük, hogy p" s" bájtmemóriára mutat, amit az Employee::operator newO foglalt le 
// felszabadítjuk a memóriát 


f 


j 


Az eddig rejtélyes size t paraméter haszna most világossá válik. Ez ugyanis a ténylegesen 
törlendő objektum mérete. Ha egy ,sima" Employee-t törlünk, akkor paraméterértékként 
sizeof(Employee)J-t; ha egy Manager-t, akkor sizeof(Manager)9-t kapunk. Természetesen az 
adott osztály egyedi memóriafoglalója tárolhatja az ilyen információt (mint ahogy az általá- 
nos célúnak is meg kell ezt tennie) és nem törődhet az oberator deleteO függvény size tpa- 
raméterével. Ez azonban nehezebbé teszi egy általános célú memóriafoglaló sebességének 
és memóriafogyasztásának javítását. 


Honnan tudja a fordítóprogram a deleteO operátort a megfelelő méretettel ellátni? Könnyen, 
amíg a delete műveletnek átadott típus azonos az objektum tényleges típusával. Ez azonban 


nincs mindig így: 


class Manager : public Employee ( 


int level; 
via 
J; 
void JO 
( 
Employee? pb - new Manager; . // problémás (a pontos típus ismerete elvész) 
delete bp; 
j 


Ekkor a fordítóprogram nem fogja tudni a pontos méretet. A tömb törléséhez hasonlóan itt 
is a programozó segítségére van szükség; az Employee bázisosztályban meg kell adni egy 
virtuális destruktort: 
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class Employee f 
public: 
void? operator neu(size D; 
void operator delete(void" , size 1; 
virtual -EmployeeO; 
I ati 
J; 


Akár egy üres destruktor is megteszi: 


Employee::-EmployeeO f ? 


A memória felszabadítását a (méretet ismerő) destruktor végzi. Sőt ha az Employee-ben van 
destruktor, akkor ez biztosítja, hogy minden belőle származtatott osztálynak lesz 
destruktora (és így tudja a méretet), akkor is, ha a származtatott osztályban nem szerepel 
felhasználói destruktor: 


void JO 
( 
Employeet p - new Manager; 
delete p; // most már jó (az Employee többalakú) 


j 
A memória lefoglalása egy (a fordítóprogram által létrehozott) hívással történik: 


Employee::operator new(sizeof(Manager)) 


A felszabadításról szintén egy (a fordítóprogram által létrehozot) hívás gondoskodik: 


Employee::operator delete(p,sizeof(Manager)) 


Vagyis ha olyan memóriafoglaló felszabadító párt akarunk írni, amely származtatott osztá- 
lyokkal is jól működik, akkor vagy virtuális destruktort kell írni a bázisosztályban, vagy nem 
szabad felhasználni a felszabadítóban a size t paramétert. Természetesen meg lehetett vol- 
na úgy tervezni a nyelvet, hogy ne legyen szükség ilyen megfontolásokra, de ez csak a ke- 
vésbé biztonságos rendszerekben lehetséges optimalizálások előnyeiről való lemondás 
árán történhetett volna. 
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15.6.1. Memóriafoglalás tömbök számára 


Az operator new és az operator deleteO függvények lehetővé teszik, hogy a programozó 
végezze az egyes objektumok számára a memóriafoglalást és -felszabadítást. Az operator 
neul JO és az operator deletel JÓ pontosan ugyanezt a szerepet játssza a tömbök esetében: 


class Employee f 

bublic: 
voidt operator neul ksize D; 
void operator delete[ void" ); 


VSE 
J; 
void f(int 5) 
( 
Employee? p - new Employeels]; 
Pet 
deletel[ ] p; 


j 


Itt a szükséges memóriát a 
Employee::operator neul I(sizeof(Employee)" st-delta) 


hívás fogja biztosítani, ahol a delta az adott fordítótól függő minimális többlet. A memóriát 
az alábbi hívás szabadítja fel: 


Employee::operator deletel I(p9; / felszabadít s" sizeo(flEmployee)--delta bájtot 


Az elemek s számát (illetve a delta-t) a rendszer , megjegyzi". Ha a deletel 10-et egy- helyett 
kétparaméteres formában adtuk volna meg, a hívásban a második paraméter 
st sizeoffEmployee) --delta lett volna. 


15.6.2. , Virtuális konstruktorok" 


Miután virtuális destruktorokról hallottunk, nyilvánvaló a kérdés: , lehetnek-e 
a konstruktorok is virtuálisak?". A rövid válasz az, hogy nem. A kicsit hosszabb: nem, de 
a kívánt hatás könnyen elérhető. Egy objektum létrehozásához a konstruktornak tudnia kell 
a létrehozandó objektum pontos típusát. Ezért a konstruktor nem lehet virtuális. Ráadásul 
a konstruktor nem egészen olyan, mint a közönséges függvények. Például olyan módokon 
működik együtt a memóriakezelő eljárásokkal, ahogy a közönséges függvények nem. Ezért 
nincs konstruktorra hivatkozó mutató. 
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Mindkét megszorítás megkerülhető egy konstruktort meghívó és a létrehozott objektumot 
visszaadó függvény készítésével. Ez kedvező, mert gyakran hasznos lehet, ha a pontos tí- 
pus ismerete nélkül tudunk új objektumot létrehozni. Az Ival box. maker osztály (412.4.4) 
pontosan erre a célra szolgált. Itt az ötlet egy másik változatát mutatom be, ahol egy osztály 
objektumai a felhasználóiknak képesek saját maguk másolatát átadni: 


class Expr ( 

bublic: 
ExprO; // alapértelmezett konstruktor 
Expr(const Expre ); // másoló konstruktor 


virtual Expr: new exprO f return new ExprO; ) 
virtual Expr" cloneO f return new ExprC this); ) 
VÉ 


34 


Mivel a new exprO-hez és a clone0-hoz hasonló függvények virtuálisak és közvetett úton 
objektumokat hoznak létre, gyakran hívják őket , virtuális konstruktornak", bár az elneve- 
zés némileg félrevezető. Mindegyik egy konstruktort használ, hogy megfelelő objektumot 
hozzon létre. 


Egy származtatott osztály felülírhatja a new exprO és/vagy cloneO függvényt, hogy egy sa- 
ját típusú objektumot adjon vissza: 


class Cond : public Expr f 
bublic: 

CondO; 

Cond(const Condé ); 


Cond? new exprO f return new CondO; ) 
Cond" cloneO f return new CondC this); ) 
sas 

75 


Ez azt jelenti, hogy egy Expr osztályú objektumhoz a felhasználó , pontosan ugyanolyan tí- 
pusú" objektumot tud létrehozni: 


void user(Expr" p) 

t 
Expr" p2 - b--xnew exprO; 
Já 

J 


A p2-höz rendelt mutató megfelelő, bár ismeretlen típusú. 
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A Cond::new exprO és a Cond::cloneO visszatérési típusa Cond" és nem Expr" , ezért egy 
Cond információvesztés nélkül lemásolható ( klónozható"): 


void user (Cond? pc, Expr" pe) 


( 
Cond?t p2 - pc-2cloneO); 
Cond" p3 - pe-xcloneO; // hiba 
17 -de 


j 


A felülíró függvények típusa ugyanaz kell, hogy legyen, mint a felülírt virtuális függvényé, 
de a visszatérési érték típusa kevésbé szigorúan kötött. Vagyis ha az eredeti visszatérési ér- 
ték B" volt, akkor a felülíró függvény visszatérési értéke lehet D" is, feltéve, hogy B nyilvá- 
nos bázisosztálya D-nek. Ugyanígy egy B£ visszatérési érték Dk-ra módosítható. 


Jegyezzük meg, hogy a paramétertípusok hasonló módosítása típushibához vezetne (lásd 


§15.8[12D. 


15.7. Tanácsok 


[1] Ha tulajdonságok unióját akarjuk kifejezni, használjunk közönséges többszörös 
öröklődést. §15.2, §15.2.4. 

[2] A tulajdonságoknak a megvalósító kódtól való elválasztására használjunk több- 
szörös öröklődést. §15.2.5. 

[3] Használjunk virtuális bázisosztályt, ha egy hierarchia némely (de nem mindegyik) 
osztályára nézve közös dolgot akarunk kifejezni. §15.2.5. 

[4] Kerüljük a típuskényszerítést (casD. §15.4.5. 

[5] Ha az adott osztályhierarchia bejárása elkerülhetetlen, használjuk 
a dynamic cast-ot. §15.4.1. 

I6] A typeid helyett részesítsük előnyben a dynamic cast-ot. §15.4.4. 

[71 A protected-del szemben részesítsük előnyben a private-et. §15.3.1.1. 

[8] Adattagokat ne adjunk meg védettként. §15.3.1.1. 

[9] Ha egy osztály definiálja az oberator delete0-et, akkor legyen virtuális 
destruktora. §15.6. 

[10] A konstruktor vagy destruktor futása alatt ne hívjunk virtuális függvényt. §15.4.3. 

[11] Ritkán — és lehetőleg csak felülíró virtuális függvényekben - használjuk a tagne- 


vek explicit minősítését feloldás céljára. §15.2.1. 
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15.8. Gyakorlatok 


11. 


12. 


(1) Írjunk olyan pir. cast sablont, amely ugyanúgy működik, mint 

a dynamic cast, de a 0-val való visszatérés helyett bad cast kivételt vált ki. 

(2) Írjunk olyan programot, amely egy objektum létrehozása közben az RTTI- 
hez viszonyítva mutatja be a konstruktorhívások sorrendjét. Hasonlóan mutassuk 
be az objektum lebontását. 

(3.5) Írjuk meg a Reversi/Othello társasjáték egy változatát. Minden játékos le- 
hessen élő személy vagy számítógép. Először a program helyes működésére 
összpontosítsunk, és csak azután arra, hogy a program annyira ,okos" legyen, 
hogy érdemes legyen ellene játszani. 

(3) Javítsunk a §415.8[3]-beli játék felhasználói felületén. 

(3) Készítsünk egy grafikus objektumosztályt egy művelethalmazzal, amely 
alapján grafikus objektumok egy könyvtára számára közös bázisosztály lehet. 
Nézzünk bele egy grafikus könyvtárba, hogy ott milyen műveletek vannak. Hoz- 
zunk létre egy adatbázis-objektum osztályt egy művelethalmazzal, amely alapján 
elhihető, hogy közös bázisosztálya az adatbázisban mezők sorakérnt tárolt objek- 
tumoknak. Vizsgáljunk meg egy adatbázis-könyvtárat, hogy ott milyen műveletek 
vannak. Határozzunk meg egy grafikus adatbázis-objektumot többszörös öröklő- 
déssel és anélkül, és hasonlítsuk össze a két megoldás előnyeit és hátrányait. 
(2) Írjuk meg a §15.6.2-beli clone0 művelet egy olyan változatát, amely a para- 
méterben megkapott Arena-ba (§10.4.11) teszi a lemásolt objektumot. Készítsünk 
egy ,egyszerű Arend"-t mint az Arena-ból származó osztályt. 

(2) Anélkül, hogy belenéznénk a könyvbe, írjunk le annyi C---kulcsszót, 
amennyit csak tudunk. 

(2) Írjunk szabványos C--4-programot, amelyben legalább tíz különböző kulcs- 
szó szerepel egymás után, úgy, hogy nincs azonosítókkal, operátorokkal vagy 
írásjelekkel elválasztva. 

(2.5) Rajzoljuk le a §15.2.4-beli Radio objektum memóriakiosztásának egy lehetsé- 
ges változatát. Magyarázzuk el, hogyan lehetne egy virtuális függvényt meghívni. 
(3) Gondoljuk meg, hogyan lehet a dynamic cast-ot megvalósítani. Készítsünk 
egy dcast sablont, amely úgy viselkedik, mint a dynamic cast, de csak az álta- 
lunk meghatározott függvényekre és adatokra támaszkodik. Gondoskodjunk ar- 


ról, hogy a rendszert a dcast vagy az előzőleg megadott osztályok megváltoztatá- 
sa nélkül lehessen új osztályokkal bővíteni. 

(2) Tegyük fel, hogy a függvényparaméterek típus-ellenőrzési szabályai a vissza- 
térési értékre vonatkozóakhoz hasonlóan enyhítettek, tehát egy Derived?" para- 
méterű függvény felülírhat egy Baset-ot. Írjunk egy programot, ami konverzió 
nélkül elrontana egy Derived típusú objektumot. Írjuk le a paramétertípusokra 


vonatkozó felülírási szabályok egy biztonságos enyhítését. 


Harmadik rész 


A standard könyvtár 


Ebben a részben a C--- standard könyvtárát mutatjuk be. Megvizsgáljuk a könyvtár szerke- 
zetét és azokat az alapvető módszereket, amelyeket az egyes elemek megvalósításához 
használtak. Célunk az, hogy megértsük, hogyan kell használni ezt a könyvtárat, illetve 
szemléltessük azokat az általános módszereket, amelyeket tervezéskor és programozáskor 


használhatunk. Ezenkívül bemutatjuk azt is, hogyan bővíthetjük a könyvtárat, pontosabban 
a rendszer fejlesztői hogyan képzelték el a továbbfejlesztést. 


Fejezetek 


16. A könyvtár szerkezete és a tárolók 

17. Szabványos tárolók 

18. Algoritmusok és függvényobjektumok 
19. Bejárók és memóriafoglalók 

20. Karakterláncok 

21. Adatfolyamok 

22. Számok 


,:..§ te, Marcus, oly sok mindent adtál nekem, ím én adok neked most egy jótanácsot. Sok 
ember légy. Hagyd el a régi játékot, hogy mindig csak ugyanaz a Marcus Cocoza vagy. 
Túlontúl sokat vessződtél már Marcus Cocozával, míg végül valósággal a rabszolgája lettél. 
Szinte semmit sem teszel anélkül, hogy ne mérlegelnéd, vajon milyen hatással lesz Marcus 
Cocoza boldogságára és tekintélyére. Szüntelen félelemben élsz, hogy Marcus Cocoza 
esetleg valami ostobaságot követ el, vagy elunja magát. Dehát mit számít mindez valójában? 
Az emberek az egész világon ostobaságokat művelnek... Szeretném ha felszabadulnál, ha 
szíved újra megtalálná békéjét. Mostantól fogva ne csak egy, hanem több ember légy, 
annyi, amennyit csak el tudsz gondolni..." 


(Karen Blixen: Álmodozók; Kertész Judit fordítása) 
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, Újdonság volt. 

Egyedi volt. Egyszerű volt. 
Biztos, hogy sikeres lesz!" 
(H. Nelson) 


Tervezési szempontok a standard könyvtárhoz "e A könyvtár szerkezete s Szabványos fejállo- 
mányok "e Nyelvi támogatás e A tárolók szerkezete 9 Bejárók e Bázisosztállyal rendelkező 
tárolók e Az STL tárolói s vector s Bejárók e Elemek elérése e Konstruktorok 9 Módosítók 
e Listaműveletek s Méret és kapacitás e vectorcbool: s Tanácsok s Gyakorlatok 


16.1. A standard könyvtár 


Minek kell szerepelnie a C-t standard könyvtárában? A programozó szempontjából az tű- 
nik ideálisnak, ha egy könyvtárban megtalál minden olyan osztályt, függvényt, és sablont, 
ami érdekes, jelentős és eléggé általános. A kérdés azonban most nem az, hogy egy könyv- 
tárban mi legyen benne, hanem az, hogy a standard könyvtár milyen elemeket tartalmaz- 
zon. Az előbbi kérdés esetében ésszerű megközelítés, hogy minden elérhető legyen, az 
utóbbi esetben azonban ez nem alkalmazható. A standard könyvtár olyan eszköz, amelyet 
minden Ct--változat tartalmaz, így minden programozó számíthat rá. 
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A C44 standard könyvtára a következő szolgáltatásokat nyújtja: 


1. Támogatja a nyelv lehetőségeinek használatát, például a memóriakezelést 
(46.2.6) és a futási idejű típusinformáció (RTTI, §15.4) kezelését. 

2. Információkat ad az adott nyelvi változat egyedi tulajdonságairól, például 
megadja a legnagyobb /loat értéket (422.2). 

3. Elérhetővé teszi azokat a függvényeket, amelyeket nem lehet a nyelven belül 
optimálisan elkészíteni minden rendszer számára (például sgrtO), §22.3 
vagy memmoveC) §19.4.0). 

4. Olyan magas szintű szolgáltatásokat nyújt, amelyekre a programozó más rend- 
szerre átvihető (hordozható) programok készítésekor támaszkodhat, például 
listákat (417.2.2), asszociatív tömböket (map) (§17.4.1), rendező függvényeket 
(§18.7.1) és bemeneti/kimeneti adatfolyamokat (21. fejezeb. 

5. Keretet biztosít a könyvtár elemeinek továbbfejlesztésére, például szabályokkal 
és eszközökkel segíti, hogy a felhasználó ugyanolyan bemeneti/kimeneti felüle- 
tet biztosíthasson saját típusaihoz, mint a könyvtár a beépített típusokhoz. 

6. További könyvtárak közös alapjául szolgál. 

Néhány további eszközt — például a véletlenszám-előállítókat (422.7) — csak azért helyeztek 
a standard könyvtárba, mert így használatuk kényelmes és hagyományosan itt a helyük. 


A könyvtár tervezésekor leginkább az utolsó három szerepkört vették figyelembe. Ezek 
a szerepek erősen összefüggnek. A hordozhatóság például olyan általános fogalom, amely 
fontos tervezési szempont minden egyedi célú könyvtár esetében. A közös tárolótípusok 
(például a listák vagy asszociatív tömbök) pedig igen jelentősek a külön fejlesztett könyv- 
tárak kényelmes együttműködésének biztosításában. 


Az utolsó pont különösen fontos a tervezés szempontjából, mert ezzel korlátozható a stan- 
dard könyvtár hatóköre és gátat szabhatunk a szolgáltatások özönének. A karakterlánc- és 
listakezelő lehetőségek például a standard könyvtárban kaptak helyet. Ha ez nem így tör- 
tént volna, akkor a külön fejlesztett könyvtárak csak a beépített típusok segítségével mű- 
ködhetnének együtt egymással. Ugyanakkor a mintaillesztő és a grafikai lehetőségek nem 
szerepelnek itt, mert — bár tagadhatatlanul széles körben használatosak — nem kimondottan 
a külön fejlesztett könyvtárak közötti együttműködést szolgálják. 


Ha egy lehetőség nem feltétlenül szükséges a fenti szerepkörök teljesítéséhez, akkor azt 
megvalósíthatjuk külön, a standard könyvtáron kívül is. Azzal, hogy kihagyunk egy szolgál- 
tatást a standard könyvtárból, azt a lehetőséget is nyitva hagyjuk a további könyvtárak szá- 
mára, hogy ugyanazt az ötletet más-más formában valósítsák meg. 
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16.1.1. Tervezési korlátozások 


A standard könyvtárak szerepköreiből számos korlátozás következik a könyvtár szerkeze- 


tére nézve. A Ctt standard könyvtára által kínált szolgáltatások tervezésekor az alábbi 
szempontokat tartották szem előtt: 


9. 


. Komoly segítséget jelentsen lényegében minden tanuló és profi programozó 


számára, közéjük értve a további könyvtárak fejlesztőit is. 


. Közvetve vagy közvetlenül minden programozó felhasználhassa az összes olyan 


célra, ami a könyvtár hatáskörébe esik. 


. Elég hatékony legyen ahhoz, hogy a későbbi könyvtárak előállításában komoly 


vetélytársa legyen a saját kezűleg előállított függvényeknek, osztályoknak és 
sablonoknak. 


. Mentes legyen az eljárásmód szabályozásától, vagy lehetőséget adjon rá, hogy 


a felhasználó paraméterként határozza meg az eljárásmódot. 


. Legyen primitív, a matematikai értelemben. Egy olyan összetevő, amely két, 


gyengén összefüggő feladatkört tölt be, kevésbé hatékony, mint két önálló 
komponens, amelyeket kimondottan az adott szerep betöltésére fejlesztettek ki. 


. Legyen kényelmes, hatékony és elég biztonságos a szokásos felhasználási terü- 


leteken. 


. Nyújtson teljeskörű szolgáltatásokat ahhoz, amit vállal. A standard könyvtár fon- 


tos feladatok megvalósítását is ráhagyhatja más könyvtárakra, de ha egy feladat 
teljesítését vállalja, akkor elegendő eszközt kell biztosítania ahhoz, hogy az 
egyes felhasználóknak és fejlesztőknek ne kelljen azokat más módszerekkel 
helyettesíteniük. 


. Legyen összhangban a beépített típusokkal és műveletekkel és biztasson azok 


használatára. 
Alapértelmezés szerint legyen típusbiztos (mindig helyesen kezelje a különböző 
típusokaD. 


10. Támogassa az általánosan elfogadott programozási stílusokat. 
11. Legyen bővíthető úgy, hogy a felhasználó által létrehozott típusokat hasonló 


formában kezelhessük, mint a beépített és a standard könyvtárban meghatáro- 
zottakat. 


Rossz megoldás például, ha egy rendező függvénybe beépítjük az összehasonlítási mód- 


szert, hiszen ugyanazok az adatok más-más szempont szerint is rendezhetők. Ezért a C stan- 
dard könyvtárának gsortO függvénye paraméterként veszi át az összehasonlítást végző 
függvényt, és nem valamilyen rögzített műveletre (például a c operátorra) hivatkozik (§7.7). 
Másrészről ebben a megoldásban minden egyes összehasonlítás alkalmával meg kell hív- 
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nunk egy függvényt, ami többletterhet jelent a gsortO eljárást felhasználó további eljárások- 
ban. Szinte minden adattípus esetében könnyen elvégezhetjük az összehasonlítást, anélkül, 
hogy függvényhívással rontanánk a rendszer teljesítményét. 


Jelentős ez a teljesítményromlás? A legtöbb esetben valószínűleg nem. Egyes algoritmusok 
esetében azonban ezek a függvényhívások adják a végrehajtási idő jelentős részét, ezért 
ilyenkor a felhasználók más megoldásokat fognak keresni. Ez a problémát a §13.4 pontban 
oldottuk meg, ahol bemutattuk, hogyan adhatunk meg összehasonlítási feltételt egy sablon- 
paraméterrel. A példa szemléltette, hogy a hatékonyság és az általánosság két egymással 
szemben álló követelmény. Egy szabvány könyvtárnak azonban nem csak meg kell valósí- 
tania feladatait, hanem elég hatékonyan kell azokat elvégeznie ahhoz, hogy a felhasználók- 
nak eszébe se jusson saját eljárásokat írni az adott célra. Ellenkező esetben a bonyolultabb 
eszközök fejlesztői kénytelenek kikerülni a standard könyvtár szolgáltatásait, hiszen csak 
így maradhatnak versenyképesek. Ez pedig nem csak a könyvtárak fejlesztőinek okoz sok 
többletmunkát, hanem azon felhasználók életét is megnehezíti, akik platformfüggetlen 
programokat szeretnének készíteni vagy több, külön fejlesztett könyvtárat szeretnének 
használni. 


A , primitívség" és a ,kényelmesség a szokásos felhasználási területeken" követelmények is 
szemben állnak egymással. Egy szabvány könyvtárban az első követelmény azonnal kizár 
minden optimalizálási lehetőséget arra nézve, hogy felkészüljünk a gyakori esetekre. 
Az olyan összetevők azonban, amelyek általános, de nem primitív szolgáltatásokat nyújta- 
nak, szerepelhetnek a standard könyvtárban a , primitívek" mellett, de nem helyettük. 
A kölcsönös kizárás nem akadályozhat bennünket abban, hogy mind a profi, mind az alkal- 
mi programozó életét egyszerűbbé tegyük. Azt sem engedhetjük meg, hogy egy összetevő 
alapértelmezett viselkedése homályos vagy veszélyes legyen. 


16.1.2. A standard könyvtár szerkezete 


A standard könyvtár szolgáltatásait az szd névtérben definiálták és fejállományok segítségé- 
vel érhetjük el azokat. Ezek a fejállományok jelzik a könyvtár legfontosabb részeit, így fel- 
sorolásukból áttekintést kaphatunk a kínált eszközökről. Ezek szerint nézzük végig 
a könyvtárat a most következő fejezetekben is. 


Ezen alfejezet további részében a fejállományokat soroljuk fel, szerepeik szerint csoporto- 
sítva. Mindegyikről adunk egy rövid leírást is és megemlítjük, hol található részletes elem- 
zésük. A csoportosítást úgy választottuk meg, hogy illeszkedjen a standard könyvtár szer- 
kezetéhez. Ha a szabványra vonatkozó hivatkozást adunk meg (például §s5.18.19, akkor az 
adott lehetőséget itt nem vizsgáljuk részletesen. 


Ha egy szabványos fejállomány neve c betűvel kezdődik, akkor az egy szabványos C 
könyvtárbeli fejállomány megfelelője. Minden cX.h: fejállományhoz, amely a C standard 
könyvtárának részeként neveket ad meg a globális névtérben, létezik egy ccX: megfelelő, 
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amely ugyanazon neveket az szd névtérbe helyezi (49.2.2). 





Tárolók 








Lvector: 
alist2 
Idegue: 
cgueuez 
Cstack: 
wZmap: 
Lxaset- 
cbitset2 





T típusú elemek egydimenziós tömbje 


T típusú elemek kétirányú listája 

T típusú elemek kétvégű sora 

T típusú elemekből képzett sor 

T típusú elemekből képzett verem 
T típusú elemek asszociatív tömbje 
T típusú elemek halmaza 

logikai értékek tömbje 


§16.3 

§17.2.2 
§17.2.3 
§17.3.2 
§17.3.1 
§17.4.1 
§17.4.3 
§17.5.3 





A multimap és multiset asszociatív tárolókat sorrendben a Cmap?, illetve a cset: állomány- 


ban találhatjuk meg. A priority gueue osztály a cgueue: fájlban szerepel. 





Általános eszközök 








Zutility: 


Ixmemoryz 
Ictime- 





Lfunctional: 


operátorok és párok 
függvényobjektumok 
memóriafoglalók a tárolókhoz 
C stílusú dátum- és időkezelés 


§17.1.4, §17.4.1.2 
§18.4 

§19.4.4 

§s.20.5 





A cmemory? fejállomány tartalmazza az auto pbtr sablont is, amely elsősorban arra használ- 


ható, hogy simábbá tegyük a mutatók és kivételek együttműködését (414.4.2). 





Bejárók 








Literator: 





bejárók és kezelésük 


19. fejezet 
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A bejárók Citerator) lehetővé teszik, hogy a szabványos algoritmusokat általánosan használ- 
hassuk a szabványos tárolókban és más hasonló típusokban (42.7.2, §19.2.1. 





Algoritmusok 








zalgorithm: általános algoritmusok 18.fejezet 
zcstdlib: bsearchO gsortO 418.11 











Egy szokványos általános algoritmus egyformán alkalmazható bármilyen típusú elemek 
bármilyen sorozatára (§3.8, §18.3). A C standard könyvtárában szereplő bsearchO és gsortO 
függvények csak a beépített tömbökre használhatók, melyek elemeihez a felhasználó nem 
határozhat meg sem másoló konstruktort, sem destruktort (§7.7). 





Ellenőrzések, diagnosztika 








Zexception: kivételosztály §14.10 

cstdexcept: szabványos kivételek §14.10 

Icassert: hibaellenőrző makró §24.3.7.2 
(feltételezett érték biztosítása) 

Icerrnoz C stílusú hibakezelés §20.4.1 











A kivételkezelésre támaszkodó hibaellenőrzést a §24.3.7.1 pontban vizsgáljuk meg. 











Karakterláncok 
cstring2 T típusú elemekből álló karakterlánc 20. fejezet 
Lcctybe: karakterek osztályozása §20.4.2 
Zcwtype: , széles" karakterek osztályozása §20.4.2 
Zcstring2 C stílusú karakterláncokat §20.4.1 
kezelő függvények 
Icwchar: C stílusú széles karakterláncok kezelése  §20.4 
zcstidlib: C stílusú karakterláncokat §20.4.1 
kezelő függvények 
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A ccstring? fejállományban szerepelnek az strlenO), strcpyO stb. függvények. A ccstdlib: 
adja meg az atofO és atoi0 függvényeket, amelyek a C stílusú karakterláncokat alakítják 
számértékekre. 











Ki- és bemenet 
Ziosfwd: előzetes deklarációk 421.1 
az [/O szolgáltatásokhoz 
Ziostream: szabványos bemeneti adatfolyamok §21.2.1 
objektumai és műveletei 
Liosz bemeneti adatfolyamok bázisosztályai $21.2.1 
cstreambuf: átmeneti tár adatftolyamokhoz §21.6 
Zistream: bemeneti adatfolyam sablon §21.3.1 
Zostream: kimeneti adatfolyam sablon §21.2.1 
Liomanip: adatfolyam-módosítók (manipulátorok) §21.4.6.2 
csstream: adatfolyamok 421.5.3 
karakterláncból/karakterláncba 
zcstdlib: karakterosztályozó függvények 420.4.2 
ístream: adatfolyamok fájlokból fájlokba §21.5.1 
Zcstdioz a printfO függvénycsalád 421.8 
Icwchar: brintfO szolgáltatások 421.8 
, széles" karakterekre 











Az adatfolyam-módosítók (manipulator) olyan objektumok, melyek segítségével az adatfo- 
lyamok állapotát megváltoztathatjuk (§21.4.69. (Például módosíthatjuk a lebegőpontos szá- 
mok kimeneti formátumát.) 





Nemzetközi szolgáltatások 








clocalez 
aclocalez 


kulturális eltérések ábrázolása §21.7 
kulturális eltérések ábrázolása C stílusban §421.7 











A locale az olyan kulturális eltérések meghatározására szolgál, mint a dátumok írásmódja, 
a pénzegységek jelölésére használt szimbólumok vagy a karakterláncok rendezésére vonat- 
kozó szabályok, melyek a különböző természetes nyelvekben és kultúrákban jelentősen 
eltérhetnek. 
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A programnyelvi elemek támogatása 
climitsz numerikus értékhatárok 422.2 
aclimitsz C stílusú, numerikus, skalár érték- 422.2.1 
határokat megadó makrók 
zcfloat- C stílusú, numerikus, lebegőpontos 422.2.1 
értékhatárokat megadó makrók 
Lanew: dinamikus memóriakezelés §16.1.3 
Ztypeinfo: futási idejű típusazonosítás támogatása §15.4.1 
Zexception: — kivételkezelés támogatása §14.10 
Zcstddef- C könyvtárak nyelvi támogatása §6.2.1 
Zcstidarg? változó hosszúságú paraméterlistával §7.6 
rendelkező függvények kezelése 
Zcsetjmp: C stílusú verem-visszatekerés $s.18.7 
zcstdlib: programbefejezés §9.4.1.1 
Ictime: rendszeróra §D.4.4.1 
Zcsignal: C stílusú szignálkezelés SD.4.4.1 








A ccstddef- fejállomány határozza meg azt a típust, amit a sizeofO függvény visszaad 
(size D, a mutatóknak egymásból való kivonásakor keletkező érték típusát (pirdiff D és 
a hírhedt NULL makrót (§5.1.1). 





Numerikus értékek 








Zcomplex: komplex számok és műveletek 422.5 
Zvalarray: numerikus vektorok és műveletek §22.4 
Cnumeric: általánosított numerikus műveletek §22.6 
Icmath: általános matematikai műveletek 422.3 
zcsidlib: C stílusú véletlenszámok 422.7 











A hagyományt követve az abs(), és divO függvény a ccstdlib: fejállományban található, bár 
matematikai függvények lévén jobban illenének a ccmath: fájlba. (422.3) 


A felhasználók és a könyvtárak fejlesztői nem bővíthetik vagy szűkíthetik a szabványos fej- 
állományokban szereplő deklarációk körét. A fejállományok jelentését úgy sem módosít- 
hatjuk, hogy megpróbálunk makrókat megadni az állományok beszerkesztése előtt vagy 
megváltoztatjuk a deklarációk jelentését azzal, hogy saját deklarációkat készítünk a fejállo- 
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mány környezetében (49.2.3). Bármely program, amely nem tartja be ezeket a játékszabá- 
lyokat, nem nevezheti magát a szabványhoz igazodónak, és az ilyen trükköket alkalmazó 
programok általában nem vihetők át más rendszerre. Lehet, hogy ma működnek, de az 
adott környezet legkisebb változása használhatatlanná teheti őket. Tartózkodjunk az ilyen 
szemfényvesztéstől. 


Ahhoz, hogy a standard könyvtár valamely lehetőséget használhassuk, a megfelelő fejállo- 
mányt be kell építenünk (include). Nem jelent a szabványnak megfelelő megoldást, ha 
a megfelelő deklarációkat saját kezűleg adjuk meg programunkban. Ennek oka az, hogy bi- 
zonyos nyelvi változatok a beépített szabványos fejállományok alapján optimalizálják a for- 
dítást, mások pedig a standard könyvtár szolgáltatásait optimalizálják, attól függően, milyen 
fejállományokat használtunk. Általában igaz, hogy a fejlesztők olyan formában használhat- 
ják a szabványos fejállományokat, amelyre a programozók nem készülhetnek fel és prog- 


ramjaik készítésekor nem is kell tudniuk ezek szerkezetéről. 


Ezzel szemben a programozó specializálhatja a szolgáltatás-sablonokat, például a swapO 
sablon függvényt (416.3.9), így ezek jobban igazodhatnak a nem szabványos könyvtárak- 
hoz és a felhasználói típusokhoz. 


16.1.3. Nyelvi elemek támogatása 

A standard könyvtárnak egy kis része a nyelvi elemek támogatásával foglalkozik, azaz 
olyan szolgáltatásokat nyújt, amelyekre a program futtatásához azért van szükség, mert 
a nyelv eszközei ezektől függően működnek. 

Azon könyvtári függvényeket, amelyek a new és delete operátorok kezelését segítik, 
a §6.2.6, a §10.4.11, a §14.4.4 és a §15.6 pontban mutattuk be. Ezek a cnew: fejállományban 


szerepelnek. 


A futási idejű típusazonosítás elsősorban a type info osztályt jelenti, amely a Ctypeinfo: fej- 
állományban található és a §15.4.4 pont írt le. 


A szabványos kivételek osztályait a §14.10 pontban vizsgáltuk, helyük a cnew:, 
a Ctybeinfo2, az Ciosz, az Cexception?, illetve az csidexcept: fejállományban van. 


A program elindításáról és befejezéséről a §3.2, a §9.4 és a §10.4.9 pontban volt szó. 
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16.2. A tárolók szerkezete 


A tároló Ccontainer) olyan objektum, amely más objektumokat tartalmaz. Példaképpen meg- 
említhetjük a listákat (/isD , a vektorokat (vector) és az asszociatív tömböket ( map). Általában 
lehetőségünk van rá, hogy a tárolókban objektumokat helyezzünk el vagy eltávolítsuk azo- 
kat onnan. Természetesen ez az ötlet számtalan formában megvalósítható. A C-4- standard 
könyvtárának tárolóit két feltétel szem előtt tartásával fejlesztették ki: biztosítsák a lehető leg- 
nagyobb szabadságot a felhasználónak új, egyéni tárolók fejlesztésében, ugyanakkor nyújt- 
sanak hasonló kezelői felületet. Ez a megközelítés lehetővé teszi, hogy a tárolók hatékony- 
sága a lehető legnagyobb legyen és a felhasználók olyan programot írhassanak, amelyek 
függetlenek az éppen használt tároló típusától. 

A tárolók tervezői általában vagy csak az egyik, vagy csak a másik feltétellel foglalkoznak. 
A standard könyvtárban szereplő tárolók és algoritmusok bemutatják, hogy lehetséges egy- 
szerre általános és hatékony eszközöket létrehozni. A következőkben két hagyományos 
tárolótípus erősségeit és gyengeségeit mutatjuk be, így megismerkedhetünk a szabványos 
tárolók szerkezetével. 


16.2.1. Egyedi célú tárolók és bejárók 


A legkézenfekvőbb megközelítés egy vektor és egy lista megvalósítására az, hogy mindket- 
tőt olyan formában készítjük el, ami legjobban megfelel a tervezett céloknak: 


templatexclass T: class Vector f // optimális 
bublic: 
explicit Vector(size tn); // kezdetben n darab, TO értékű elemet tárol 
Ig operatorf k(size 0; // indexelés 
VARTA 
Ji 
templatexclass T: class List f // optimális 
bublic: 
class Link €/ ... 7); 
ListO; // kezdetben üres 
void put( TP); // az aktuális elem elé helyezés 
T? getO; // az aktuális elem megszerzése 


HM sz 
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Mindkét osztály olyan műveleteket kínál, amely ideális felhasználásukhoz, és mindkettőben 
szabadon kiválaszthatjuk a megfelelő ábrázolást, anélkül, hogy más tárolótípusokkal foglal- 
koznánk. Ez lehetővé teszi, hogy a műveletek megvalósítása közel optimális legyen. Külö- 
nösen fontos, hogy a leggyakrabban használt műveletek (tehát a but a List esetében, illet- 
ve az operatorf JO a Vector esetében) egészen rövidek és könnyen optimalizálhatóak (pl. 


helyben Cinline) kifejthetők) legyenek. 


A tárolók egyik leggyakoribb felhasználási módja, hogy egymás után végiglépkedünk a tá- 
rolóban tárolt elemeken. Ezt nevezzük a tároló bejárásának, a feladat megvalósításához 
pedig általában létrehozunk egy bejáró Gterator) osztályt, amely megfelel az adott tároló 
típusának. (411.5 és §11.14[7D 


Bizonyos esetekben, amikor a felhasználó bejár egy tárolót, nem is akarja tudni, hogy az 
adatokat ténylegesen egy listában vagy egy vektorban tároljuk. Ezekben a helyzetekben 
a bejárásnak nem szabad attól függnie, hogy a Listvagy a Vector osztályt használtuk. Az ide- 
ális az, ha mindkét esetben pontosan ugyanazt a programrészletet használhatjuk. 


A megoldást a bejáró (iterator) osztály jelenti, amely biztosít egy , kérem a következőt" mű- 
veletet, amely minden tároló számára megvalósítható. Például: 


templatexclass T-: class Itor ( // közös felület (absztrakt osztály §2.5.4, §12.3) 
bublic: 

// 0 visszaadásával jelezzük, hogy nincs több elem 

virtual Tt firstŐ — 0; // mutató az első elemre 

virtual T" next) — 0; // mutató a következő elemre 
1 


Ezt az osztályt később elkészíthetjük külön a Vector és külön a List osztályhoz: 


templatexclass T: class Vector. itor : public ItorST- f // vektor-megvalósítás 
VectorzTeg u; 
size t index; // az aktuális elem indexértéke 
bublic: 


Vector. itor( VectorzT2k vu) : v(vv), index(0) f ) 
T" firstO ( return (v.sizeO) ? kulindex-0J : O; ? 
T" next ( return (trindexxv.sizeO) ? kulindex] : O; ) 


Vai 


templatexclass T- class List itor : public ItorST: f // lista-megvalósítás 
LiSsIZT2g list; 
ListzT:2::Link p; // az aktuális elemre mutat 
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bublic: 
List itor(tistzT:£ ); 
Tt firstO; 
Tt nextO; 


J; 


Grafikus formában (szaggatott vonallal jelezve a ,megvalósítás a ... felhasználásával 
kapcsolatoD: 


Vector List 
A A 
ez ozáteő 
Vector. itor List itor 


A két bejáró (iterator) belső szerkezete jelentősen eltér, de ez a felhasználó számára látha- 
tatlan marad. Ezek után bármit bejárhatunk, amire az Itor osztályt meg tudjuk valósítani. 
Például: 


int count(Itoréchar:dé ii, char term) 


( 
int c - 0; 
for (char? p — ii firstO; p; pz-ii.nextO) if Cp--term) c4-; 
return c; 


j 


Van azonban egy kis probléma. A bejárón elvégzendő művelet lehet rendkívül egyszerű, 
mégis mindig végre kell hajtanunk egy (virtuális) függvényhívást. A legtöbb esetben ez 
a teljesítményromlás nem jelent nagy veszteséget az egyéb tevékenységek mellett. A nagy- 
teljesítményű rendszerekben azonban gyakran éppen egy egyszetű tároló gyors bejárása je- 
lenti a létfontosságú feladatot, és a függvények meghívása sokkal , költségesebb" lehet, 
mint egy egész számokkal végzett összeadás vagy egy mutatóérték-számítás (ami a Vector 
és a List esetében megvalósítja a next0 függvény0. Ezért a fenti modell nem használható, 
vagy legalábbis nem tökéletes egy szabványos könyvtár szolgáltatásaként. 
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Ennek ellenére a tároló-bejáró szemlélet nagyon jól használható sok rendszer esetében. 
Évekig ez volt programjaim kedvenc megoldása. Az előnyöket és a hátrányokat az alábbi- 
akkal foglalhatjuk össze: 


4 Az önálló tárolók (container) egyszerűek és hatékonyak. 

4 A tárolóknak nem kell hasonlítaniuk egymásra. A bejáró (iterator) és a beburko- 
ló (wrapper) osztályok (425.7.1) segítségével a külön fejlesztett tárolókat is egy- 
séges formában érhetjük el. 

t A közös felhasználói felületet a bejárók biztosítják (nem egy általános 
tárolótípus, §16.2.2). 

4  Ugyanahhoz a tárolóhoz több bejárót is definiálhatunk a különböző igényeknek 
megfelelően. 

4 A tárolók alapértelmezés szerint típusbiztosak és homogének (azaz a tároló 
minden eleme ugyanolyan típusú). Heterogén tárolókat úgy hozhatunk létre, 
hogy olyan mutatókból hozunk létre egy homogén tárolót, amelyek azonos 
őssel rendelkező objektumokra mutatnak. 

4 A tárolók nem tolakodók (non-intrusive), (azaz nem igénylik, hogy a tároló tag- 
jai egy közös őstől származzanak, vagy valamilyen hivatkozó mezővel rendel- 
kezzenek). A nem tolakodó tárolók jól használhatóak a beépített típusok, vagy 
a mi hatáskörünkön kívül létrehozott adatszerkezetek esetében. 

- . Minden bejárón keresztüli hozzáférés egy virtuális függvényhívással rontja 
a rendszer hatékonyságát. Az egyszerű hozzáférési eljárásokhoz képest ez 
a módszer komoly időveszteséget is jelenthet. 

- . A bejáró-osztályok hierarchiája könnyen áttekinthetetlenné válhat. 

- . Semmilyen közös alapot nem találhatunk a különböző tárolók között, még ke- 
vésbé a tárolókban tárolt objektumok között. Ez megnehezíti az olyan általános 
feladatokra való felkészülést, mint a perzisztencia (persistence) biztosítása vagy 
az objektum be- és kivitel. 


A 3 jellel az előnyöket, - jellel a hátrányokat soroltuk fel. 


A bejárók által biztosított rugalmasságra külön felhívnánk a figyelmet. Egy olyan közös fel- 
használói felület, mint az Itor, akkor is megvalósítható, amikor a tároló (esetünkben 
a Vector és a Lis) megtervezése és elkészítése már rég megtörtént. Amikor a tárolót tervez- 
zük, általában konkrét formában gondolkodunk, például egy tömböt vagy egy listát készí- 


tünk. Csak később látjuk meg az elvont ábrázolás azon lehetőségeit, amelyek egy adott 
környezetben egyaránt alkalmazhatóak a tömbökre és a listákra is. 


Ezt a , kései elvonatkoztatást" tulajdonképpen többször is elvégezhetjük. Például képzeljük 
el, hogy egy halmazt szeretnénk létrehozni. A halmaz teljesen más jellegű elvont ábrázolás, 
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mint az Itor, de ugyanazzal a módszerrel, amelyet az Itor esetében alkalmaztunk, készíthe- 
tünk egy halmaz jellegű felületet is a Vector és a List osztályhoz: 


Vektor List 


Áh ÁM 


Set Itor 





Vector. set Vector. itor List set List itor 


Ezért a kései elvonatkoztatás az absztrakt osztályok segítségével lehetővé teszi, hogy 
ugyanazokat a fogalmakat több, különböző formában is ábrázolhassuk, és ez akkor is igaz, 
ha az egyes megvalósításokban semmilyen hasonlóság sincs. A listák és a vektorok eseté- 
ben még találhatunk néhány nyilvánvaló hasonlóságot, de az /tor felületet akár egy istream 
számára is könnyen elkészíthetnénk. 


Elméletileg a listában szereplő utolsó két pont jelenti a szemlélet igazi hátrányát. Ez azt je- 
lenti, hogy ez a megközelítés még akkor sem lehet ideális megoldás egy szabványos könyv- 
tárban, ha a bejárók függvényhívásaiból illetve a hasonló tároló-felületekből eredő teljesít- 
ményromlást sikerült is kiküszöbölnünk (amire bizonyos helyzetekben lehetőség van). 


A nem tolakodó (non-intrusive) tárolók néhány esetben egy kicsit lassabbak és kicsit több 
helyet igényelnek, mint a tolakodó tárolók. Én magam ezt nem tartom gondnak; ha mégis 
az lenne, az Itor-hoz hasonló bejárókat tolakodó tárolókhoz is elkészíthetjük (§16.5[11). 


16.2.2. Tárolók közös őssel 


Egy tolakodó tároló elkészíthető anélkül is, hogy sablonokat (template) használnánk vagy 
bármely más módon paramétereket adnánk meg a típushoz: 


struct Link ( 
Link? pre; 
Link" suc; 
M/S 


J; 
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class List f 
Link?" head; 


Link? curr; // az aktuális elem 
bublic: 
Link? getO; // az aktuális elem eltávolítása és visszaadása 
void put(tink"); // beszűrás az aktuális elem elé 
Vess 


8 


A List itt nem más, mint Link típusú objektumok listája, azaz olyan objektumok tárolására 
képes, amelyek a Link adatszerkezetből származnak: 


class Ship : public Link €(/§ ... "/ 3; 


void f(1isr" Is) 
( 
while (Link? po - Ist-2getO) f 
if (Ship? ps - dynamic castsShip"r:(po)) f( / a Ship-nek többalakűnak kell lennie 


//(5615.4.0 
// a shib használata 
fi 
else ( 
// hoppá, valami mást csinálunk 
fi 


A Simula ebben a stílusban határozta meg szabványos tárolóit, tehát ezt a megoldást tekint- 
hetjük az objektumorientált programozást támogató nyelvek eredeti szemléletének. Napja- 
inkban minden objektum közös bázisosztályának neve Object vagy valami hasonló. 
Az Object osztály általában számos más szolgáltatást is nyújt azon kívül, hogy összekapcsol- 
ja a tárolókat. 


Ez a szemlélet gyakran (bár nem szükségszerűen) kiegészül egy általános tárolótípussal is: 


class Container : public Object f 


bublic: 
virtual Objecr" getO; // az aktuális elem eltávolítása és visszaadása 
virtual void put(Object"); // beszúrás az aktuális elem elé 
virtual Object"£ operatorf K(size 1); // indexelés 
Mé 


Vé 
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Figyeljük meg, hogy a Container osztályban szereplő műveletek virtuálisak, így a különbö- 
ző tárolók saját igényeiknek megfelelően felülírhatják azokat: 


class List : public Container f 
bublic: 

Object" getO; 

void putObject" ); 

ZÁS 


J; 


class Vector : public Container ( 
bublic: 
Objecr£ operatorf ksize 0; 
V/KE 
3 
Sajnos azonnal jelentkezik egy probléma. Milyen műveleteket kell biztosítania a Container 
osztálynak? Csak azok a függvények szerepelhetnek, amelyeket minden tároló meg tud va- 
lósítani, de az összes tároló művelethalmazának metszete nevetségesen szűk felület. Sőt, az 
az igazság, hogy az igazán érdekes esetekben ez a metszet teljesen üres. Tehát gyakorlati- 
lag a támogatni kívánt tárolótípusokban szereplő, lényeges műveletek unióját kell szerepel- 
tetnünk. A szolgáltatásokhoz biztosított felületek ilyen unióját kövér vagy bőséges felületnek 
nevezzük. (fat interface, §24.4.3) 


Vagy e felület leírásában készítünk valamilyen alapértelmezett változatot a függvényekhez, 
vagy azokat tisztán virtuálisakká (pure virtual) téve arra kötelezzük a származtatott osztá- 
lyokat, hogy ők fejtsék ki a függvényeket. Mindkét esetben sok-sok olyan függvényt 
kapunk, amelyek egyszerűen futási idejű hibát váltanak ki: 


class Container : public Object f 
bublic: 
struct Bad opf  // kivételosztály 
const char? p; 
Bad. op(const char? pp) :P(pp) ( ) 
z 


virtual void put(Object") ( throw Bad op("put-hiba"J; ? 
virtual Object" get ( throw Bad op("get-hiba"; ) 
virtual Object"£ operatorf J(Gint) ( throw Bad op(C1 J"); 
74 
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Ha védekezni szeretnénk azon lehetőséggel szemben, hogy egy tároló nem támogatja 
a get0 függvény használatát, el kell kapnunk valahol a Container::Bad op kivételt. Ezek 
után a korábbi SZip példát a következő formában valósíthatjuk meg: 


class Ship : public Object ( /? ... "/ 3; 


void fi(Container? pc) 


( 
try ( 
while (Object? po - pc-3getO) ( 
if (Ship? ps - dynamic castcShip"r(po)) ( 
// a shib használata 
, 
else f( 
// hoppá, valami mást csinálunk 
, 
, 
, 


catch (Container::Bad opk bad) ( 
// hoppá, valami mást csinálunk 
) 
j 


Ez így túlságosan bonyolult, ezért a Bad op kivétel ellenőrzését érdemes máshova helyez- 
nünk. Ha számíthatunk rá, hogy a kivételeket máshol kezelik, akkor a példát az alábbi for- 
mára rövidíthetjük: 


void fX(Container? pc) 
t 
while (Object? po - pc-:3getO) ( 
Shipg s - dynamic castsShipk:("po); 
// a Ship használata 


Ennek ellenére az az érzésünk, hogy a futási idejű típusellenőrzés stílustalan és nem is túl 
hatékony. Ezért inkább a statikus típusellenőrzés mellett maradunk: 


void fztorsShip:"? i) 


while (Ship? ps - i-:2nextO) f 
// a Ship használata 
; 
j 
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A tárolótervezés , objektumok közös bázisosztállyal" megközelítésének előnyeit és hátrá- 
nyait az alábbiakkal foglalhatjuk össze (nézzük meg a §16.5[10] feladatot is): 


- . A különböző tárolókon végzett műveletek virtuális függvényhívást eredményez- 
nek. 

- . Minden tárolót a Container osztályból kell származtatnunk. Ennek következté- 
ben kövér felületet kell készítenünk, és nagy mértékű előrelátásra, illetve futási 
idejű típusellenőrzésre van szükség. Egy külön fejlesztett tárolót egy általános 
keretbe szorítani a legjobb esetben is körülményes (§16.5[12]. 

4 A közös Container bázisosztály egyszerű megoldást kínál olyan tárolók fejlesz- 
téséhez, amelyek hasonló műveleteket biztosítanak. 

- . A tárolók heterogének és alapértelmezés szerint nem típusbiztosak. (Mindössze 
arra számíthatunk, hogy az elemek típusa Object ".) Ha szükség van rá, sablo- 
nok (template) segítségével hozhatunk létre típusbiztos és homogén tárolókat. 

- . A tárolók tolakodóak (ami esetünkben azt jelenti, hogy minden elemnek az 
Object osztályból kell származnia). Beépített típusokba tartozó objektumokat, 
illetve a mi hatáskörünkön kívül meghatározott adatszerkezeteket közvetlenül 
nem helyezhetünk el bennük. 

- . A tárolóból kiemelt elemekre megfelelő típuskonverziót kell alkalmaznunk, 
mielőtt használhatnánk azokat. 

4 A Container és az Object osztály olyan szolgáltatások kialakításához használha- 
tó, amelyek minden tárolóra vagy minden objektumra alkalmazhatók. Ez nagy- 
mértékben leegyszerűsíti az olyan általános szolgáltatások megvalósítását, mint 
a perzisztencia biztosítása vagy az objektumok ki- és bevitele. 


Ugyanúgy, mint korábban (§16.2.1), a t az előnyöket, a - a hátrányokat jelöli. 


Az egymástól független tárolókhoz és bejárókhoz viszonyítva a közös bázisosztállyal ren- 
delkező objektumok ötlete feleslegesen sok munkát hárít a felhasználóra, jelentős futási 
idejű terhelést jelent és korlátozza a tárolóban elhelyezhető objektumok körét. Ráadásul 
sok osztály esetében az Object osztályból való származtatás a megvalósítás részleteinek fel- 
fedését jelenti, ezért ez a megközelítés nagyon távol áll az ideális megoldástól egy szabvá- 
nyos könyvtár esetében. 


Ennek ellenére az ezen megoldás által kínált általánosságot és rugalmasságot nem szabad 
alábecsülnünk. Számtalan változatát, számtalan programban sikeresen felhasználták már. 
Ennek a megközelítésnek azokon a területeken van jelentősége, ahol a hatékonyság kevés- 
bé fontos, mint az egyszerűség, amelyet az egyszerű Container felület és az objektum ki- 
és bevitelhez hasonló szolgáltatások biztosítanak. 
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16.2.3. A standard könyvtár tárolói 


A standard könyvtár tárolói (container) és bejárói (iterator) — amelyet gyakran nevezünk 
STL (Standard Template Library) keretrendszernek, (43.10) — olyan megközelítésként fogha- 
tók fel, amely a korábban bemutatott két hagyományos modell előnyeit a lehető legjobban 
kiaknázza. Az STL azonban egyik módszert sem alkalmazza közvetlenül; célja az, hogy egy- 
szerre hatékony és általános algoritmusokat kínáljon, mindenféle megalkuvás nélkül. A ha- 
tékonyság érdekében az alkotók a gyakran használt adatelérő függvények esetében elve- 
tették a nehezen optimalizálható virtuális függvényeket, így nem adhattak szabványos 
felületet a tárolók és a bejárók számára absztrakt osztály formájában. Ehelyett mindegyik tá- 
rolótípus támogatja az alapvető műveleteknek egy szabványos halmazát. A kövér felületek 
problémájának (§16.2.2, §24.4.3) elkerülése érdekében az olyan műveletek, amelyek nem 
minden tárolóban valósíthatók meg hatékonyan, nem szerepelnek ebben a közös halmaz- 
ban. Az indexelés például alkalmazható a vector esetében, de nem használható a /ist táro- 
lókra. Ezenkívül minden tárolótípus saját bejárókat biztosít, amelyek a szokásos bejárómű- 
veleteket teszik elérhetővé. 


A szabványos tárolók nem közös bázisosztályból származnak, hanem minden tároló önál- 
lóan tartalmazza a szabványos tárolófelületet. Ugyanígy nincs közös bejáró-ős sem. A szab- 
ványos tárolók és bejárók használatakor nem történik futási idejű típusellenőrzés, sem 
közvetlen (explicib, sem automatikus (implicit) formában. 


A minden tárolóra kiterjedő közös szolgáltatások biztosítása igen fontos és bonyolult fel- 
adat. Az STL ezt a memóriafoglalók (allokátor, allocator) segítségével valósítja meg, amelye- 
ket sablonparaméterként adunk meg (419.4.3), ezért nincs szükség közös bázisosztályra. 


Mielőtt a részleteket megvizsgálnánk és konkrét példákat mutatnánk be, foglaljuk össze az 
STL szemlélete által biztosított előnyöket és hátrányokat: 


4 Az önálló tárolók egyszerűek és hatékonyak (nem egészen olyan egyszerűek, 
mint a tényleg teljesen független tárolók, de ugyanolyan hatékonyak). 

t Mindegyik tároló biztosítja a szabványos műveleteket szabványos néven és je- 
lentéssel. Ha szükség van rá, az adott tárolótípusnak megfelelő további művele- 
tek is megtalálhatók. Ezenkívül, a becsomagoló vagy beburkoló (wrapper) osz- 
tályok (425.7.1) segítségével a külön fejlesztett tárolók is beilleszthetők a közös 
keretrendszerbe. (416.5[14D 

t A további közös használati formákat a szabványos bejárók biztosítják. Minden 
tároló biztosít bejárókat, amelyek lehetővé teszik bizonyos műveletek végrehaj- 
tását szabványos néven és jelentéssel. Minden bejáró-típus külön létezik min- 
den tárolótípushoz, így ezek a bejárók a lehető legegyszerűbbek és a lehető 
leghatékonyabbak. 
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t A különböző szükségletek kielégítésére minden tárolóhoz létrehozhatunk saját 
bejárókat vagy általános felületeket, a szabványos bejárók mellett. 

t A tárolók alapértelmezés szerint típusbiztosak és homogének (azaz az adott 
tároló minden eleme ugyanolyan típusú). Heterogén tárolókat úgy készíthe- 
tünk, hogy egy olyan homogén tárolót hozunk létre, amely közös bázisosztályra 
hivatkozó mutatókat tartalmaz. 

4 A tárolók nem tolakodóak (azaz a tároló tagjainak nem kell egy adott bázisosz- 
tályból származniuk, vagy hivatkozó mezőket tartalmazniuk). A nem tolakodó 
tárolók a beépített típusok esetében használhatók jól, illetve az olyan adatszer- 
kezetekhez, melyeket a mi hatáskörünkön kívül határoztak meg. 

4 Az általános keretrendszer lehetővé teszi tolakodó tárolók használatát is. Termé- 
szetesen ez az elemek típusára nézve komoly megkötéseket jelenthet. 

4 Minden tároló használ egy paramétert, az úgynevezett memóriafoglalót 
(allocator), amely olyan szolgáltatások kezeléséhez nyújt segítséget, amelyek 
minden tárolóban megjelennek. Ez nagymértékben megkönnyíti az olyan általá- 
nos feladatok megvalósítását, mint a perzisztencia biztosítása vagy az objektum 
ki- és bevitel.(419.4.3) 

- . A tárolók és bejárók nem rendelkeznek olyan szabványos, futási idejű ábrázo- 
lással, amelyet például függvényparaméterként átadhatnánk (bár a szabványos 
tárolók és bejárók esetében könnyen létrehozhatnánk ilyet, ha erre az adott 
programban szükségünk van, §419.39. 


Ugyanúgy, mint eddig (§16.2.1) a 4 az előnyöket, a - a hátrányokat jelöli. 


A tárolóknak (container) és a bejáróknak Citerator) tehát nincs rögzített, általános ábrázolá- 
sa. Ehelyett minden tároló ugyanazt a szabványos felületet biztosítja szabványos műveletek 
formájában. Ennek következtében a tárolókat egyformán kezelhetjük és fel is cserélhetjük. 
A bejárókat is hasonlóan használhatjuk. Ez az idő- és tárhasználati hatékonyságot csak ke- 
véssé rontja, a felhasználó viszont kihasználhatja az egységességet, mind a tárolók szintjén 
(a közös bázisosztályból származó tárolók esetében), mind a bejárók szintjén (a specializált 
tárolók esetében). 


Az STL megközelítése erősen épít a sablonok (template) használatára. Ahhoz, hogy elke- 
rüljük a felesleges kódismétléseket, gyakran van szükség arra, hogy mutatókat tartalmazó 
tárolókban részlegesen specializált változatok készítésével közösen használható összetevő- 
ket hozunk létre (413.5). 
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16.3. A vektor 


Itt a vector-t úgy írjuk le, mint a teljes szabványos tárolók egyik példáját. Ha mást nem mon- 
dunk, a vector-ra vonatkozó állítások változtatás nélkül alkalmazhatók az összes többi szab- 
ványos tárolóra is. A 17. fejezet foglalkozik azokkal a lehetőségekkel, amelyek kizárólag 
a list, a set, a map vagy valamelyik másik tárolóra vonatkoznak. Azokat a lehetőségeket, 
amelyeket kifejezetten a vector— vagy egy hasonló tároló — valósít meg, csak bizonyos mér- 
tékig részletezzük. Célunk az, hogy megismerjük a vector lehetséges felhasználási területe- 
it és megértsük a standard könyvtár globális szerkezetében elfoglalt szerepét. 


A §17.1 pontban áttekintjük a standard tárolók tulajdonságait és az általuk kínált lehetősé- 
geket. Az alábbiakban a vector tárolót különböző szempontok szerint mutatjuk be: a tagtí- 
pusok, a bejárók, az elemek elérése, a konstruktorok, a veremműveletek, a listaműveletek, 
a méret és kapacitás, a segédfüggvények, illetve a vectorcbool: szempontjából. 


16.3.1. Típusok 


A szabványos vector egy sablon (template), amely az sid névtérhez tartozik és a Cvector: 
fejállományban található. Először is néhány szabványos típusnevet definiál: 


template class T, class A - allocatorsT: : class std::vector f 


bublic: 
// típusok 
typedef T value type; // elemtípus 
typedef A allocator. type; // memóriakezelő-típus 


typedef typename A::size type size type; 
typedef typename A::difference type difference type; 


typedef megvalósítás függől iterator; MET 
tybedef megvalósítás függő2 const iterator; // const T" 


typedef std::reverse iteratorZiterator: reverse iterator; 
typedef std::reverse iteratoráconst iterator: const reverse iterator; 


typedef typename A::pointer pointer; // elemmutató 
typedef typename A::const pointer const pointer; 
typedef typename A::reference reference; // hivatkozás elemre 


typedef typename A::const reference const reference; 
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Minden szabványos tároló definiálja ezeket a típusokat, mint saját tagjait, de a saját megva- 
lósításának legmegfelelőbb formában. 


A tároló elemeinek típusát az első sablonparaméter határozza meg, amit gyakran nevezünk 
értéktípusnak (value type) is. A memóriafoglaló típusa (allocator. type) — amelyet (nem kö- 
telezően) a sablon második paraméterében adhatunk meg - azt határozza meg, hogy 
a value type hogyan tart kapcsolatot a különböző memóriakezelő eljárásokkal. Ezen belül, 
a memóriafoglaló adja meg azokat a függvényeket, amelyeket a tároló az elemek tárolásá- 
ra szolgáló memória lefoglalására és felszabadítására használ. A memóriafoglalókról a §19.4 
pontban lesz szó részletesen. Általában a size type határozza meg azt a típust, amelyet a tá- 
roló indexeléséhez használunk, míg a difference type annak az értéknek a típusát jelöli, 
amelyet két bejáró különbségének képzésekor kapunk. A legtöbb tároló esetében ezek 
a size I, illetve a pirdijf" t típust jelentik (46.2.1) 


A bejárókat a 42.7.2 pontban mutattuk be és a 19. fejezetben foglalkozunk velük részlete- 
sen. Úgy képzelhetjük el őket, mint egy tároló valamelyik elemére hivatkozó mutatót. 
Minden tároló leír egy iterator nevű típust, amellyel az elemekre mutathatunk. Rendelkezé- 
sünkre áll egy const iterator típus is, amelyet akkor használunk, ha nincs szükség az ele- 
mek módosítására. Ugyanúgy, mint a mutatók esetében, itt is mindig használjuk a bizton- 
ságosabb const változatot, hacsak nem feltétlenül a másik lehetőségre van szükségünk. 
A vector bejáróinak konkrét típusa a megvalósítástól függ, a legnyilvánvalóbb megoldás egy 
hagyományosan definiált vector esetében a 7", illetve a const 7". 


A visszafelé haladó bejárók típusát a vector számára a szabványos reverse iterator sablon 
segítségével határozták meg. (419.2.5) Ez az elemek sorozatát fordított sorrendben szolgál- 
tatja. 


A §3.8.1 pontban bemutattuk, hogy ezen típusok segítségével a felhasználó úgy írhat táro- 
lókat használó programrészleteket, hogy a ténylegesen használt típusokról semmit sem tud, 


sőt, olyan kódot is írhat, amely minden szabványos tároló esetében használható: 


templatesclass C: typename C::value type sum(const C£ c) 


( 
typename C::value type s — O; 
typename C::const iterator p - c.beginO; // kezdés az elején 
while (p!-c.endO) ( // folytatás a végéig 
s 45 tp; // elem értékének megszerzése 
tp; // p a következő elemre fog mutatni 
j 


return S; 


J 
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A typename használata egy sablonparaméter tagjának neve előtt elég furcsán néz ki, de 
a fordítóprogram nem akad fenn rajta, ugyanis nincs általános módszer arra, hogy egy sab- 
lonparaméter valamelyik tagjáról eldöntsük, hogy az típusnév-e. (4C.13.5) 


Ugyanúgy, mint a mutatók esetében, az előtagként használt " a bejáró indirekcióját jelenti 
(42.7.2, 419.2.1D, míg a -4- a bejáró növelését végzi. 


16.3.2. Bejárók 


Ahogy az előző alfejezetben már bemutattuk, a programozók a bejárókat arra használhat- 
ják, hogy bejárják a tárolót az elemek típusának pontos ismerete nélkül. Néhány tagfügg- 
vény teszi lehetővé, hogy elérjük az elemek sorozatának valamelyik végét: 


template class T, class A - allocatorsT: : class vector f 
bublic: 
77 eaz 


// iterators: 


iterator beginO; // az első elemre mutat 

const iterator beginŐ const; 

iterator endŐ; // az "utolsó utáni" elemre mutat 
const iterator endOŐ const; 


reverse iterator rbeginO; // hátulról az első elemre mutat 
const reverse iterator rbeginŐ const; 
reverse iterator rendO; // hátulról az "utolsó utáni" elemre mutat 


const reverse iterator rendŐ const; 


Jdse 
Vai 


A beginO/end0O pár a tároló elemeit a szokásos sorrendben adja meg, azaz elsőként a , nul- 
ladik" elemet (vagyis az elsőt) kapjuk, majd sorban a következőket; az rbeginO/rendO pár- 
nál viszont fordított sorrendben, azaz az n-1. elem után következik az n-2., majd az n-3., 
és így tovább. Például ha egy iterator használatával ilyen sorozatot kapunk: 


beginŐ endO 


Sela ssz b ed e sz öl 7 ál 
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akkor a reverse iterator a következő elemsorozatot adja (§19.2.59: 


rbeginŐ rendŐ 



































Így lehetőségünk van olyan algoritmusok készítésére, amelyeknek fordított sorrendben van 
szüksége az elemek sorozatára. Például: 


templatexclass C: tybename C::iterator find last(Ck c, typename C::value tybe vu) 


( 
typename C::reverse. iterator ri - find(c.rbeginO,c.rendO, v); 
if (ri —— c.rendO) return c.endO; // a c.endŐ jelzi, hogy "nem található" 
typename C::iterator i — ri.baseO; 
return --i; 


Egy reverse iterator esetében az ri.base( függvény egy olyan bejárót ad vissza, amely az ri 
által kijelölt hely után következő elemre mutat. (§19.2.5) A visszafelé haladó bejárók nélkül 
egy ciklust kellett volna készítenünk: 


templatexclass C: tybename C::iterator find last(Ck c, typename C::value tybe vu) 
j 
typename C::iteratorp - c.endO; — // keresés a végétől visszafelé 
while (p/-c.beginO) 
if C--p--v) return p; 
return c.endO; // a c.endO jelzi, hogy "nem található" 


J 


A visszafelé haladó bejáró is közönséges bejáró, tehát írhattuk volna ezt is: 


templatexclass C: typename C:riterator find last(C£k c, typename C::value type v) 
( 
tybename C::reverse iterator p - c.rbeginO;  // a sorozat átnézése visszafelé 
while (p/!-c.rendO) f 


if Cp--v) ( 
typename C:riterator i - pb.baseO; 
return --i; 
J 
tap; // vigyázzunk: növelés, nem csökkentés (--) 


j 


return c.endO; // a c.endOŐ jelzi, hogy "nem található" 


j 
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Figyeljünk rá, hogy a C::reverse iterator típus nem ugyanaz, mint a C::iterator. 


16.3.3. Az elemek elérése 


A vector igen fontos tulajdonsága a többi tárolóval összehasonlítva, hogy az egyes eleme- 
ket bármilyen sorrendben könnyen és hatékonyan elérhetjük: 


template class T, class A - allocatorsT: : class vector f 
public: 
VE 


// hozzáférés az elemekhez 


reference operatorl (size type n); // nem ellenőrzött hozzáférés 
const reference operatorl (size type n) const; 


reference at(size type n); // ellenőrzött hozzáférés 
const reference at(size type n) const; 


reference frontO; // első elem 
const reference frontO const; 
reference backO; // utolsó elem 


const reference backO const; 


KZT 
); 


Az indexeléshez az oberatorf JÓ vagy az atO függvényt használjuk. A / / operátor ellenőri- 
zetlen hozzáférést biztosít, míg az at0 indexhatár-ellenőrzést is végez és out of range ki- 
vételt vált ki, ha a megadott index nem a megfelelő tartományba esik: 


void fvectorcint:dg v, int i1, int i2) 
try ( 
forGnt i — O; i £ v.sizeO; it1) ( 
// a tartomány már ellenőrzött, itt a nem ellenőrzött ulij-t kell használnunk 


f 
v.at(i1) — v.at(i2); // hozzáféréskor a tartomány ellenőrzése 


Üss 
j 
catch(out of range) f 
// hoppá, kicsűsztunk a tartományon kívülre 


J 


588 A standard könyvtár 


Ez a példa bemutat egy hasznos ötletet is: ha az indexhatárokat már valamilyen módon el- 
lenőriztük, akkor az ellenőrizetlen indexelő operátort teljes biztonsággal használhatjuk. El- 
lenkező esetben viszont érdemes az at0 függvényt alkalmaznunk. Ez a különbség fontos 
lehet olyan programoknál, ahol a hatékonyságra is figyelnünk kell. Ha a hatékonyság nem 
jelentős szempont vagy nem tudjuk egyértelműen eldönteni, hogy a tartomány ellenőrzött- 
e, akkor biztonságosabb ellenőrzött / / operátorral rendelkező vektort használjunk (példá- 
ul a Vec-et, §3.7.2), vagy legalábbis ellenőrzött bejárót (419.3). 


A tömbök alapértelmezett hozzáférési módja ellenőrizetlen. Biztonságos (ellenőrzötb) szol- 
gáltatásokat megvalósíthatunk egy gyors alaprendszer felett, de gyors szolgáltatást lassú 
alaprendszer felett nem. 


A hozzáférési műveletek reference vagy const reference típusú értéket adnak vissza, attól 
függően, hogy konstans objektumra alkalmaztuk-e azokat. Az elemek elérésére a referencia 
megfelelő típus. A vectorcX: legegyszerűbb és legkézenfekvőbb megvalósításában 
a reference egyszerűen X£, míg a const reference megfelelője a const X£. Ha egy indexha- 
táron kívüli elemre próbálunk hivatkozni, az eredmény meghatározhatatlan lesz: 


void fwvectorzdoublex£k v) 
( 


double d — uv[v.sizeO[; // nem meghatározható: rossz indexérték 


listcchar? list; 
char c - Ist. frontO; // nem meghatározható: a lista üres 


J 


A szabványos sorozatok közül csak a vector és a degue (§17.2.3) támogatja az indexelést. 
Ennek oka az, hogy a rendszer tervezői nem akarták a felhasználókat alapvetően rossz ha- 
tásfokú műveletek bevezetésével megzavarni. Az indexelés például nem alkalmazható a lisz 
típusra (417.2.2), mert veszélyesen rossz hatásfokú eljárás lenne (konkrétabban: O(n)). 


A frontO és backO tagfüggvények sorrendben az első, illetve az utolsó elemre hivatkozó 
referenciákat adnak vissza. Akkor igazán hasznosak, ha biztosan tudjuk, hogy léteznek 
ezek az elemek és programunkban valamiért különösen fontosak. Ennek gyakori esete, 
amikor egy vektort veremként (stack, §16.3.5) akarunk használni. Jegyezzük meg, hogy 
a frontO arra az elemre ad hivatkozást, amelyre a beginO egy bejárót. A frontO úgy is el- 
képzelhető, mint maga az első elem, míg a begin inkább az első elemre hivatkozó muta- 
tó. A backO és az endŐ közötti kapcsolat egy kicsit bonyolultabb: a backO az utolsó elem, 
míg az endŐ egy mutató az , utolsó utáni" pozícióra. 
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16.3.4. Konstruktorok 


Természetesen a vector a konstruktoroknak, destruktoroknak és másoló műveleteknek is 
teljes tárházát kínálja: 


template class T, class A - allocatorsT: : class vector f 
bublic: 

ÚT sé 

// konstruktorok, stb. 


explicit vector(const A£ - A09; 
explicit vector(size type n, const Ik val - TO, const Ag —- A09; // n darab val 
template cclass In: // az In-nek bemeneti bejárónak kell lennie (§19.2.1) 


vectordn first, In last, const Ag —- 409; // másolás [first:last(-ból 
vector(const vectorgt Xx); 


—vectorO; 


vectork operator—-(const vectorg Xx); 


template cclass In: // az In-nek bemeneti bejárónak kell lennie (§19.2.1) 
void assign(In first, In las; // másolás (first:last[-ból 

void assign(size type n, const Ik vaD; // n darab val 

Mas 


j; 
A vector gyors hozzáférést tesz lehetővé tetszőleges eleméhez, de méretének módosítása vi- 
szonylag bonyolult. Ezért általában a vector létrehozásakor megadjuk annak méretét is: 


vectorcxRecord: vur(10000); 


void f(int s1, int s2) 
í 


vectorsint: vi(s 1); 


vectorcdouble:? p - new vectorcdouble:(s29; 


J 


Az ilyen módon létrehozott vektorelemeknek az elemek típusának megfelelő alapértelme- 
zett konstruktorok adnak kezdőértéket, tehát a ur vektornak mind a 10 000 elemére lefut 
a RecordO függvény, a vi si darab elemének pedig egy-egy intO hívás ad kezdőértéket. 
Gondoljunk rá, hogy a beépített típusok alapértelmezett konstruktora az adott típusnak 
megfelelő 0 értéket adja kezdőértékül. (44.9.5, §10.4.2) 
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Ha egy típus nem rendelkezik alapértelmezett konstruktorral, akkor belőle nem hozhatunk 


létre vektort, hacsak nem adjuk meg az összes elem kezdőértékét. Például: 


class Num ( // végtelen pontosság 
bublic: 
Numcdlong); 
// nincs alapértelmezett konstruktor 
Mé 
3; 
vectoréNum: v1(10009; // hiba: nincs alapértelmezett Num 
vectoréNum: v2(1000 Num(0)); // rendben 


Mivel egy vector nem tárolhat negatív számú elemet, így méretének nemnegatív számnak 
kell lennie. Ez azon követelményben jut kifejezésre, hogy a vektor size tybe típusának 
unsigned-nak kell lennie. Ez bizonyos rendszerekben nagyobb vektorméret használatát te- 
szi lehetővé, egyes esetekben viszont meglepetésekhez is vezethet: 


void f(int i) 

( 
vectorcchar? vcO(-1; // a fordító erre könnyen figyelmeztethet 
vectorcchar: vc1(i); 


J 


void gO 


( 
HK-D; // becsapjuk fO-et, hogy elfogadjon egy igen nagy pozitív számot 
? 


J 


Az f(-1 hívásban a -1 értéket egy igen nagy pozitív számra alakítja a rendszer (4C.6.3). Ha 
szerencsénk van, fordítónk figyelmeztet erre. 


A vector méretét közvetve is megadhatjuk, úgy, hogy felsoroljuk a kezdeti elemhalmazt. Ezt 
úgy valósíthatjuk meg, hogy a konstruktornak azon értékek sorozatát adjuk át, amelyekből 
a vektort fel kell építeni: 


void f(const lisizx:k Is) 
( 


vectorSX? v1I(lst.beginO, lst.endO);  // elemek másolása listából 


char pl ] - "despair"; 


vectoréchar: v2Xb,£plsizeot(p)-1D;  // karakterek másolása C stílusú karakterláncból 


J 
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Minden esetben a vector konstruktora számítja ki a vektor méretét, miközben a bemeneti 
sorozatból átmásolja az elemeket. 


A vector azon konstruktorait, melyek egyetlen paramétert igényelnek, az explicit kulcsszó- 
val deklaráljuk, így véletlen konverziók nem fordulhatnak elő (411.7.1: 


vectorcint: v1(109; // rendben: 10 egészből álló vektor 

vectorsint: v2 — vectorcint:(10)9; // rendben: 10 egészből álló vektor 

vectorsint: v3 — v2; // rendben: v3 v2 másolata 

vectorsint: vá — 10; // hiba: automatikus konvertálás kísérlete 10-ről vectorsint2-re 


A másoló konstruktor és a másoló értékadás a vector elemeit másolják le. Egy sok elemből 
álló vektor esetében ez hosszadalmas művelet lehet, ezért a vektorokat általában referen- 
ciaként adjuk át: 


void fi(vectorcsint2£ ); // szokásos stílus 
void f2(const vectorzint2£ ); // szokásos stílus 
void f3(vectorsint?); // szokatlan stílus 
void hO 

( 


vectorsint: v(10000); 
TÁS 


JI) / hivatkozás átadása 
J2(w);  / hivatkozás átadása 
J3(;  // a 10 000 elem új vektorba másolása az f30 számára 


Az assign függvények a többparaméteres konstruktorok párjainak tekinthetők. Azért van 
rájuk szükség, mert az - egyetlen, jobb oldali operandust vár, így ha alapértelmezett para- 
méterértéket akarunk használni vagy értékek teljes sorozatát akarjuk átadni, az assign függ- 
vényre van szükségünk: 


class Book ( 
Ma 
43 


void fwvectorkNum:£ un, vectorcchar:£ vc, vectorSBook:£ vb, listcBook:£k lb) 


( 


vn.assignC10, Num(0)); // Num(0) tíz példányát tároló vektor értékil adása un-nek 
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char s[ ] — "Iliterál"; 


vc.assign(s,£ slsizeot(5)-1D; // a "literál" értékül adása vc-nek 
vb.assign(lb.beginO,lb.endO); // listaelemek értékül adása 
17 érés 


Ezek után egy vector objektumot feltölthetünk tetszőleges elemsorozattal, ami típus szerint 
megfelelő, és később is hozzárendelhetünk az objektumhoz ilyen sorozatokat. Fontos, 
hogy ezt anélkül értük el, hogy nagyszámú konstruktort illetve konverziós operátort kellett 
volna definiálnunk. Figyeljük meg, hogy az értékadás teljes egészében lecseréli a vektor 
elemeit. Elméletileg az összes régi elemet töröljük, majd az új elemeket beillesztjük. AZ ér- 
tékadás után a vector mérete az értékül adott elemek számával egyezik meg: 


void JO 

( 
vectorcchar?: v(10,x; // v.size )-—10, minden elem értéke Xx" 
v.assign(5, a); // v.size 0-—5, minden elem értéke a! 
4 ss 


j 


Természetesen, amit az assignO csinál, az megvalósítható közvetetten úgy is, hogy először 
létrehozzuk a kívánt vektort, majd ezt adjuk értékül: 


void fXvectorcBook:£ vh, listcBook:£k lb) 


( 
vectorSBook? vt(lb.beginO,lb.endO 9; 
vh — ut; 
jease 


j 


Ez a megoldás azonban nem csak csúnya, de rossz hatásfokú is lehet. 


Ha egy vektor konstruktorában két ugyanolyan típusú paramétert használunk, akkor azt 
kétféleképpen is értelmezhetnénk: 


vectorsint- v(10,509; // vector(méret érték) vagy vector(bejáró1, bejáró2)? 
// vector(méret, érték)! 


Az int nem bejáró, így a megvalósításoknak biztosítaniuk kell, hogy a megfelelő konstruk- 
tor fusson le: 


vector(vectorcint:::size tybe, const intik, const vectorcint:::allocator. type ); 
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A másik lehetséges konstruktor a következő: 


vector(vectorcsint:::iterator, vectorsint:::iterator, const vectorsint:::allocator. typed ); 


A könyvtár ezt a problémát úgy oldja meg, hogy megfelelő módon túlterheli a konstruk- 
torokat, de hasonlóan kezeli az assignO és az insertO (§16.3.6) esetében előforduló több- 
értelműséget is. 


16.3.5. Veremműveletek 


A vektort általában úgy képzeljük el, mint egy egységes adatszerkezetet, melyben az ele- 
meket indexeléssel érhetjük el. Ezt a szemléletet azonban el is felejthetjük és a vektort a leg- 
elvontabb legáltalánosabb) sorozat megtestesítőjének tekinthetjük. Ha erre gondolunk és 
megfigyeljük, hogy a tömböknek, vektoroknak milyen általános felhasználási területei van- 


nak, nyilvánvalóvá válik, hogy a vector osztályban a veremműveletekre is szükség lehet: 


template class T, class A - allocatorsT: : class vector f 
bublic: 
177 


// veremműveletek 


void push back(const Ig Xx); // hozzáadás a végéhez 
void pop backO; // az utolsó elem eltávolítása 
I vő 

h 


Ezek a függvények a vektort veremnek tekintik és annak végén végeznek műveleteket: 


void Kvectorcchar:£ 5) 
f 
s.push backCa); 
s.push back( b); 
s.push back( c); 
s.pop backO; 
if (sls.sizeO-1] !- b) errorC Lehetetlen! "); 
s.pop. backO; 


if (s.bacRO !/- 1a) error( "Ennek soha nem szabad megtörténnie!"); 
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Amikor meghívjuk a push backO függvényt, az s vektor mérete mindig nő egy elemmel és 
a paraméterként megadott elem a vektor végére kerül. Így az s/5.sizeO-1] elem (ami ugyan- 
az, mint az s.backO által visszaadott érték, §16.3.3) a verembe legutoljára helyezett elem lesz. 


Attól eltekintve, hogy a vector szót használjuk a szack helyett, semmi szokatlant nem művel- 
tünk. A back utótag azt hangsúlyozza ki, hogy az elemet a vektor végére helyezzük, nem 
pedig az elejére. Egy új elem elhelyezése a vektor végén nagyon költséges művelet is lehet, 
hiszen annak tárolásához további memóriát kell lefoglalnunk. Az adott nyelvi változatnak 
azonban biztosítania kell, hogy az ismétlődő veremműveletek csak ritkán okozzanak mé- 
retnövekedésből eredő teljesítnénycsökkenést. 


Figyeljük meg, hogy a pop backO függvény sem ad vissza értéket. Egyszerűen törli a legutol- 
só elemet és ha azt szeretnénk megtudni, hogy a kiemelés (pop) előtt milyen érték szerepelt 
a verem tetején, akkor azt külön meg kell néznünk. Ezt a típusú vermet sokan nem kedve- 
lik (42.5.3, §2.5.4), de ez a megoldás hatékonyabb lehet és ez tekinthető a szabványnak is. 


Miért lehet szükség veremszerű műveletekre egy vektor esetében? Egy nyilvánvaló indok, 
hogy a verem megvalósítására ez az egyik lehetőség (§417.3.1), de ennél gyakoribb, hogy 
a tömböt folyamatosan növekedve akarjuk létrehozni. Elképzelhető például, hogy ponto- 
kat akarunk beolvasni egy tömbbe, de nem tudjuk, összesen hány pontot kapunk. Ez eset- 
ben arra nincs lehetőségünk, hogy már kezdetben a megfelelő méretű tömböt hozzuk lét- 
re és utána csak egyszerűen beleírjuk a pontokat. Ehelyett a következő eljárást kell végre- 
hajtanunk: 


vectorZPoint: cities; 


void add points(Point sentinel) 


( 
Point buj; 


while (cin 5: buf) ( 
if (buf -- sentineD return; 
// új pont ellenőrzése 
cities push back(buf); 

j 


j 
Ez a megoldás biztosítja, hogy a vector igény szerint növekedhessen. Ha mindössze annyi 
a teendőnk, hogy a pontokat elhelyezzük a vektorban, akkor a cities adatszerkezetet feltölt- 
hetjük közvetlenül egy konstruktor segítségével is (416.3.4), általában azonban valamilyen 
módon még fel kell dolgoznunk a beérkező adatokat és csak fokozatosan tölthetjük fel 
a vektort a program előrehaladtával. Ilyenkor használhatjuk a bush backO függvényt. 
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A C programokban ez a leggyakoribb felhasználási területe a reallocO függvénynek, amely 
a C standard könyvtárában szerepel. Ezért a vektor — és általában minden szabványos táro- 
ló — biztosít egy általánosabb, elegánsabb, de nem kevésbé hatékony változatot a reallocO 
helyett. 


A vektor méretét (sizeO) a push backO automatikusan növeli, így nem fordulhat elő, hogy 
a vektor túlcsordul (mindaddig, amíg memória igényelhető a rendszertől, §19.4.19. Alulcsor- 
dulás ellenben előfordulhat: 


void JO 
( 
vectorcint? v; 
v.pop backO; // nem meghatározható hatás: v állapota nem 
// meghatározható lesz 
vpush back(7); // nem meghatározható hatás (v állapota nem 
// meghatározható), valószínűleg rossz 
J 


Az alulcsordulás következménye nem meghatározható és a legtöbb C----változat esetében 
olyan memóriaterület felülírását eredményezi, amely nem tartozik a vektorhoz. Az alulcsor- 
dulást ugyanúgy el kell kerülnünk, mint a túlcsordulást. 


16.3.6. Listaműveletek 


A push backO, a pop bacRO és a backO művelet (§16.3.5) lehetővé teszi, hogy a vector osz- 
tályt veremként használjuk. Bizonyos helyzetekben azonban arra is szükségünk lehet, hogy 
a verem közepére illesszünk be, vagy onnan távolítsunk el egy elemet: 


template class T, class A - allocatorsT: : class vector f 


bublic: 
VS 
// listaműveletek 
iterator insert(iterator pos, const Ik Xx); // x felvétele pos elé 
void insert(iterator pos, size type n, const Ig Xx); // n darab x felvétele pos elé 
template cclass In: // az In-nek bemeneti bejárónak kell lennie (§19.2. 1) 


void insert(iterator pos, In first, In las0); // elemek beillesztése sorozatból 


iterator erase(iterator pos); // a pos pozícióban levő elem eltávolítása 


iterator erase(iterator first, iterator last); // a sorozat törlése 
void clearO; // minden elem törlése 
KESO 
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Ezen műveletek működésének bemutatásához egy gyümölcsök (frui) neveit tartalmazó 
vektort hozunk létre. Először is meghatározzuk a vektort, majd feltöltjük néhány névvel: 


vectorsstring? fruit; 


JÍfruitpush back("ószibarack"); 
JÍfruitpush backC"alma"); 
JÍfruitpush back(C kivi"); 

JÍfruitpush back(C( körte"); 
JÍfruitpush back(Ccsillaggyümölcs"); 
JÍfruitpush backCszólő"); 


Ha hirtelen elegünk lesz azokból a gyümölcsökből, melyek neve k betűvel kezdődik, ak- 
kor ezeket a következő eljárással törölhetjük ki: 


sort(fruit.beginO fruit.endO); 

vectorsstring?::iterator p1 - find ifffruit.beginO fruit.endO, initial k); 
vectorsstring:::iterator p2 - find if(P1 fruit.endO, initial not(k)); 
JÍruit.erase(p1,p29; 


Tehát rendezzük a vektort, megkeressük az első és az utolsó gyümölcsöt, melynek neve k 
betűvel kezdődik, végül ezeket töröljük a fruit objektumból. Hogyan készíthetünk olyan 
függvényeket, mint az initial(x) — amely eldönti, hogy a kezdő karakter x betű-e — vagy az 
initial not(x), amely akkor ad igaz értéket, ha a kezdőbetű nem x? Ezzel a kérdéssel ké- 
sőbb, a §18.4.2 pontban foglalkozunk részletesen. 


Az erase(p1,p2) művelet D1-től p2-ig törli az elemeket (a p2 elem marad). Ezt a következő- 
képpen szemléltethetjük: 


Jruitf ]: 
bi b2 
alma csillaggyümölcs kivi körte őszibarack szőlő 


Az erase(p1 p2) törli a kivi és a körte elemet, tehát a végeredmény a következő lesz: 


Jruitl ]: 


alma  csillaggyümölcs őszibarack szőlő 
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Szokás szerint, a programozó által megadott sorozat az első feldolgozandó elemtől az utol- 
só feldolgozott elem utáni pozícióig tart. 


Esetleg eszünkbe jut az alábbi megoldással próbálkozni: 


vectorsstring2::iterator p1 - find ifffruit.beginŐ fruit.endO,initialCk?); 
vectorsstring3::reverse iterator p2 - find, ifffruit.rbeginO fruit.rendO, initialCk?); 
Jruit.erase(p1,p2- 1; // hoppá! típushiba 


Azonban a vectorsfruit:::iterator és a vectorSfruit:::reverse iteratornem feltétlenül azonos 
típusú, így nem használhatjuk őket együtt az erase0 függvény hívásakor. Ha egy 
reverse iterator értéket egy iterator értékkel együtt akarunk használni, akkor az előbbit át 
kell alakítanunk: 


Jfruit.erase(p1,p2.baseO); // iterator kinyerése reverse iterator-ból (§19.2.5) 


Ha egy vektorból elemeket törlünk, akkor megváltozik annak mérete és a törölt elem után 
szereplő értékeket a felszabadult területre kell másolnunk. Példánkban a /fruit.sizeO értéke 
4-re változik, és az őszibarack, amire eddig /ruit/5/ néven hivatkozhattunk, most már 
JÍruitl3/-ként lesz elérhető. 


Természetesen arra is lehetőségünk van, hogy egyetlen elemet töröljünk. Ebben az esetben 
csak az erre az elemre mutató bejáróra van szükség (és nem egy bejáró-párra): 


Jfruit.erase(findffruit.beginO fruit.endO, "őszibarack" ); 
Jfruit.erase(fruit.begin 04 1); 


Ez a két sor törli az őszibarack-ot és a csillaggyűümölcs-öt, így a fruit vektorban már csak két 
elem marad: 


Jruitf ]: 


alma szőlő 


Arra is lehetőségünk van, hogy egy vektorba elemeket illesszünk be. Például: 


Jfruit.insertffruit.beginOs 1, "cseresznye"; 
Jruit.insert(fruit.endO, "ribizli"; 
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Az új elem a megadott elem elé kerül, az utána következő elemek pedig elmozdulnak, hogy 
az új elemet beszúrhassuk. Az eredmény: 


fruit ]: 


alma cseresznye szőlő ribizli 


Figyeljük meg, hogy az f.insertffendO,x) egyenértékű az fipush back(x) művelettel. 
Teljes sorozatokat is beilleszthetünk egy vektorba: 


Jruit.insert(fruit.beginO-4- 2, citrus .beginO, citrus.endO ); 


Ha a citrus egy másik tároló, amely így néz ki: 


citrusl J: 
citrom grapefruit narancs lime 


akkor a következő eredményt kapjuk: 


fruit ]: 


alma cseresznye citrom grapefruit narancs lime szőlő ribizli 


Az insertO függvény a citrus elemeit átmásolja a fruit vektorba. A citrus tároló változatlan 
marad. 


Kétségtelen, hogy az insertŐ és az erase0 általánosabbak, mint azok a műveletek, melyek 
csak a vektor végének módosítását teszik lehetővé (§16.3.5). Éppen emiatt azonban sokkal 
több gonddal is járhatnak. Például ahhoz, hogy az insertŐ egy új elemet beillesszen, eset- 
leg az összes korábbi elemet át kell helyeznie a memóriában. Ha sokszor használunk telje- 
sen általános beszúró és törlő műveleteket egy tárolón, akkor ennek a tárolónak esetleg 
nem is vector-nak, hanem inkább 7ist-nek kéne lennie. A /isz tároló hatékonyan képes 
együttműködni az insertO és az erase0) műveletekkel, de az indexelés ez esetben nehézkes 


(416.3.3). 


A beszúrás és a törlés a vector esetében esetleg sok-sok elem áthelyezésével jár, (míg a list 
vagy az asszociatív tárolók — például a map — esetében ez elkerülhető). Ennek következté- 
ben előfordulhat, hogy a vector egyik elemére mutató izerator egy insertŐ vagy egy eraseO 
művelet végrehajtása után egy másik, vagy akár egy egyáltalán nem létező elemre mutat. 
Soha ne próbáljunk meg elérni elemeket érvénytelen bejárón keresztül, mert az eredmény 
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meghatározhatatlan lesz és általában végzetes következményekkel jár. Különösen veszé- 
lyes egy olyan bejáró használata, amely a beszúrás helyét jelölte ki, mert az insertO az első 
paraméterét érvénytelenné teszi: 


void duplicate elements(vectorsstring:k f) 


t 
Jfor(wvectorsstring2::iterator p - f.beginO; p!-f.endO; 44p) f.insert(p,"p); . / Nem! 


J 


Erre kell gondolnunk majd a §16.5[15] feladatnál is. A vector adott változata az új p elem be- 
szúrásához esetleg az összes elemet áthelyezné, de a p utániakat biztosan. 


A clearO művelet a tároló összes elemét törli. Ezért a c.clearO a c.erase(c.beginO,c.endO) 
rövidítésének tekinthető. A c.clearO végrehajtása után a c.size0 értéke O lesz. 


16.3.7. Az elemek kiválasztása 


A legtöbb esetben az erase0 és az insertŐ célpontja egy jól meghatározott hely, például 
a beginŐ vagy az endŐ eredménye, valamilyen keresési eljárás (például a findO) által 
visszaadott érték vagy egy bejárással megtalált elempozíció. Ezekben az esetekben rendel- 
kezésünkre áll egy bejáró, amely a kívánt elemet jelöli ki. A vector (és a vektorszerű táro- 
lók) elemeit azonban meghatározhatjuk indexeléssel is. Hogyan állíthatunk elő egy olyan 
bejárót, amely az insertŐ vagy az eraseO utasításban megfelelő paraméter a 7-es sorszámú 
elem kijelöléséhez? Mivel ez a hetedik elem a vektor elejétől számítva, így a c.beginO- 7 ki- 
fejezés jelenti a megoldást. A további lehetőségek, amelyek a tömbökhöz való hasonlóság 
miatt felmerülhetnek bennünk, gyakran nem működnek. Például gondoljuk végig a követ- 
kező eseteket: 


templatexclass C: void (Ck c) 


( 
c.erase(c.begin 03 7); // rendben (ha c bejárói támogatják a 4 műveletet 
// (§19.2.1)) 
c.erase(k c[7D; // nem általános 
c.erase(ct 7); // hiba: 7 hozzáadása egy tárolóhoz nem értelmezhető 
c.erase(c.backO); // hiba: c.backO referencia, nem bejáró 
c.erase(c.endO-2); // rendben (utolsó előtti előtti elem) 
c.erase(c.rbegin0429; // hiba: vector::reverse iterator és vector::iterator 
// különböző típusok 
c.erase((c.rbegin042).baseO); // zavaros, de jó (§19.2.5) 
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A legcsalogatóbb lehetőség a £c/7/, amely a vector legnyilvánvalóbb megvalósításában 
használható is, hiszen a c/7/egy létező elem, és ennek címe használható bejáróként. A c vi- 
szont lehet egy olyan tároló is, ahol a bejáró nem egy egyszerű mutató valamelyik elemre. 
A map index-operátora (417.4.1.3) például egy mapped typek típusú referenciát, és nem 
egy elemre hivatkozó referenciát (value typek) ad vissza. 


A bejáróra nem minden tároló esetében használható a 4 művelet. A /ist például még 
a c.begin0t7 forma használatát sem támogatja. Ha feltétlenül hetet kell adnunk egy 
list::iterator objektumhoz, akkor a -- operátort kell ismételgetnünk. 


A cs 7és a c.backO forma egyszerűen típushibát eredményez. A tároló nem numerikus vál- 
tozó, amelyhez hetet hozzáadhatnánk, a c.backO pedig egy konkrét elem - például a , kör- 
te" értékkel, amely nem határozza meg a körte helyét a c tárolóban. 


16.3.8. Méret és kapacitás 


A vector osztályt eddig úgy próbáltuk meg bemutatni, hogy a lehető legkevesebbet szóljunk 
a memóriakezelésről. A vector szükség szerint növekszik. Általában ennyit éppen elég tud- 
nunk. Ennek ellenére lehetőségünk van rá, hogy közvetlenül a vector memóriahasználatá- 
ról kérdezzünk, és bizonyos helyzetekben érdemes is élnünk ezzel a lehetőséggel. Az ilyen 
célú műveletek a következők: 


template class T; class A - allocatorST: : class vector f 


bublic: 
VES 
// kapacitás 
size type sizeO const; // elemek száma 
bool emptyO const f return size0——0; ) 
size type max sizeO const; // a lehetséges legnagyobb vektor mérete 
void resize(size type sz, T val - TO; // a hozzáadott elemeknek val ad kezdőértéket 
size type capacityO const; // az elemek számának megfelelő lefoglalt memória mérete 
void reserve(size type n); // hely biztosítása összesen n elem számára; nem adunk 


// kezdőértéket 
// length error kiváltása, ha n2max sizeO 


Mek 
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A vector minden pillanatban valahány elemet tárol. Az éppen tárolt elemek számát a size 
függvénnyel kérdezhetjük le és a resize0 segítségével módosíthatjuk. Tehát a programozó 
meg tudja állapítani a vektor méretét és meg tudja azt változtatni, ha a vektor szűknek vagy 
túl nagynak bizonyul: 


class Histogram ( 
vectorcint: count; 
bublic: 
Histogram(int h) : count(max(h,8)) (? 
void record(int 1); 
za 
J; 


void Histogram::record(int i) 

( 
if G20) i - 0; 
if (count.sizeOOSzi) count.resize(iti); // sok hely kell 
countf[ijat; 


J 


A resizeO használata egy vector esetében nagyon hasonlít arra, amikor a C standard könyv- 
tárának reallocO függvényét használjuk egy dinamikusan lefoglalt C tömb esetében. 


Amikor egy vektort átméretezünk, hogy több (vagy kevesebb) elemet tároljunk benne, el- 
képzelhető, hogy az összes elem új helyre kerül a memóriában. Ezért átméretezhető vekto- 
rok elemeire hivatkozó mutatókat nem tárolhatunk akármeddig, egy resizeO utasítás után 
ugyanis ezek már felszabadított memóriaterületre mutatnak. Ehelyett nyilvántarthatunk in- 
dexértékeket. Soha ne felejtsük el, hogy a push backO, az insertŐ és az erase0 is átmére- 
tezi a vektort. 


Ha a programozó tudja, hogy a vektor mérete a későbbiekben mennyire nőhet, esetleg ér- 
demes a reserve() függvény segítségével előre lefoglalnia a megfelelő méretű területet a ké- 
sőbbi felhasználáshoz: 


struct Link ( 
Link? next; 
LTinkCink? n -0) : nextn) () 
I sza 

73 


vectorcLink: u; 


void chain(size tn) // v feltöltése n számú Link-kel, melyek az előző Link-re mutatnak 


( 
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v.reserve(n ); 

v.push back(tink(099; 

for (int i - 1; iZn; it) v.push back(tink(kvuli-1))); 
Iza 


j 


A v.reserve(rn) függvényhívás biztosítja, hogy a v méretének növelésekor mindaddig nem 
lesz szükség memóriafoglalásra, amíg v.size() meg nem haladja n értékét. 


A szükséges memóriaterület előzetes lefoglalásának két előnye van. Az egyik, hogy még 
a legegyszerűbb nyelvi változat is egyetlen művelettel lefoglalhat elegendő memóriaterüle- 
tet, és nem kell minden lépésben lassú memóriaigénylést végrehajtania. Ezenkívül a leg- 
több esetben számolhatunk egy logikai előnnyel is, amely talán még fontosabb, mint a ha- 
tékonysági szempont. Amikor egy vector mérete megnő, akkor elméletileg minden elem 
helye megváltozhat a memóriában. Ennek következtében minden olyan jellegű láncolás, 
amilyet az előbbi példában létrehoztunk az elemek között, csak akkor használható, ha 
a reserve) garantálja, hogy az elemek memóriabeli helye nem változik meg a vektor felépí- 
tése közben. Tehát bizonyos esetekben a reserveO biztosítja programunk helyességét, 
amellett, hogy hatékonysági előnyöket is jelent. 


Ugyanezt a biztonságot nyújtja az is, ha csak kiszámítható időközönként fordulhat elő, hogy 
a vector számára lefoglalt terület elfogy és egy bonyolult művelettel át kell helyeznünk az 
addig tárolt elemeket. Ez nagyon fontos lehet olyan programok esetében, melyeknek szi- 
gorú futási idejű korlátozásoknak kell megfelelniük. 


Fontos megjegyeznünk, hogy a reserveO nem változtatja meg a vektor (logikai) méretét, 


ezért az új elemeknek sem kell kezdőértéket adnia. Tehát mindkét szempontból ellentéte- 
sen viselkedik, mint a resizeO. 


Ugyanúgy, ahogy a sizeO az éppen tárolt elemek számát adja meg, a capacityO függvény 
a lefoglalt memória-egységek számáról tájékoztat. Így a c.capacityO-c.sizeO kifejezés azt 
adja meg, hogy még hány elemet hozhatunk létre újbóli memóriafoglalás nélkül. 


A vektor méretének csökkentésével nem csökkentjük annak kapacitását. Az így felszaba- 


dult területek tehát megmaradnak a vector-ban a későbbi növekedést segítendő. 


Ha a felszabadult területet vissza szeretnénk adni a rendszernek, egy kis trükkhöz kell 
folyamodnunk: 


vector Link: tmp — u; // v másolata alapértelmezett kapacitással 
v.swap(tmp); // most v rendelkezik az alapértelmezett kapacitással (§16.3.9) 
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A vector az elemek tárolásához szükséges memóriaterületet úgy foglalja le, hogy meghívja 
(a sablonparaméterként megadott) memóriafoglaló tagfüggvényeit. Az alapértelmezett me- 
móriafoglaló, melynek neve allocator (§19.4.1), a new operátort használja a memóriafogla- 
láshoz, így egy bad alloc kivételt vált ki, ha már nincs elég szabad memória. Más memória- 
foglalók más módszert is követhetnek (419.4.2). 


A reserveO és capacityO függvények csak az olyan egységes, ,tömör" tárolók esetében 
használhatók, mint a vecztor. A list-hez például ilyen szolgáltatás nem áll rendelkezésünkre. 


16.3.9. További tagfüggvények 


Nagyon sok algoritmus — köztük a fontos rendező eljárások — elemek felcserélésével dolgo- 
zik. A csere (413.5.2) legegyszerűbb megvalósítása, hogy egyszerűen átmásolgatjuk az ele- 
meket. A vector osztályt azonban általában olyan szerkezet ábrázolja, amely az elemek le- 
íróját (handle) tárolja (413.5, §17.1.3). Így két vector sokkal hatékonyabban is felcserélhető, 
ha a leírókat cseréljük fel. A vector::swapO függvény ezt valósítja meg. Az alapértelmezett 
swapO nagyságrendekkel lassabb, mint a fenti eljárás: 


template class T, class A - allocatorsT: : class vector f 
bublic: 
Ve 


void swap(vectorg ); 


allocator. type get allocatorO const; 


3 


A get allocatorO függvény lehetőséget ad a programozónak arra, hogy elérje a vector me- 
móriafoglalóját (416.3.1, §16.3.4). Erre a szolgáltatásra általában akkor van szükségünk, ami- 
kor egy, a vektorhoz kapcsolódó adatnak a programban ugyanúgy akarunk memóriát fog- 
lalni, mint a vector-nak magának (419.4.1) 


16.3.10. Segédfüggvények 


Két vector objektumot az —- és a £ operátor segítségével hasonlíthatunk össze: 


template class T, class Az 
bool std::operator-—(const vectorST,A2£ x, const vectorST,A2£ y); 
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template class T; class Az 
bool std::oberator£(const vectorST,A2£ x, const vectorST,A2£ yJ; 


A u] és a v2 vector akkor egyenlő, ha v]1.size 0-—v2.size0 és v1(n]J--v2n] minden értelmes 
n index esetén. Hasonlóan, a c a nyelvi elemek szerinti rendezést jelenti, tehát a c művele- 
tet a vector esetében a következőképpen határozhatjuk meg: 


template class T, class Az 
inline bool std::operatorS(const vectorST,A2£ x, const vectorzT, Ax y) 


( 
return lexicographical compare (x.beginO,x.endO,y.beginO,y.endO); // lásd §18.9 


J/ 


Ez azt jelenti, hogy x akkor kisebb, mint y, ha az első olyan .x/i/ elem, amely nem egyezik 
meg a megfelelő )/i/ elemmel, kisebb, mint )/i/ vagy x.size0gy.size0) és minden x/i/ meg- 
egyezik a megfelelő )/í/ értékkel. 


A standard könyvtár az —— és a c definíciójának megfelelően meghatározza a /-, a c-, a 5, 
és a 5— operátott is. 


Mivel a swapO egy tagfüggvény, v1.swap(v2) tormában hívhatjuk meg. Nem minden típus- 
ban szerepel azonban a swapO tagfüggvény, így az általános algoritmusok a swap(a, b) for- 
mát használják. Ahhoz, hogy ez a forma a vector-ok esetében is működjön, a standard 
könyvtár a következő specializációt adja meg: 


template class T, class A: void std::swap(vectorcT,A2£ x, vectorcT, Act y) 


( 
x.swap(y); 


j 


16.3.11. VectorCbool- 


A vectorgbool: specializált osztály (§413.5) logikai értékeknek egy tömörített vektorát való- 
sítja meg. Egy bool típusú változót is meg kell tudnunk címezni, így az legalább egy bájtot 
foglal. A vectorcbool: osztályt azonban könnyen elkészíthetjük úgy is, hogy minden elem 
csak egy bitet foglaljon. 


A szokásos vector műveletek ugyanolyan jelentéssel használhatók a vectorcboot: esetében is. 
Különösen fontos, hogy az indexelés és a bejárás is elvárásainknak megfelelően működnek: 
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void Kvectorsboob:g v) 


( 


for Gnt i - O; izv.sizeO; 441) cin 55 ulil; // ciklus index használatával 


typedef vectorSbool:::const. iterator VI; 
for (VI p - v.beginO; p!-v.endO; 43p) coutsátp; // ciklus bejárók 
// használatával 


Ennek eléréséhez utánozni kell a bitenkénti címzést. Mivel egy mutató az egy bájtnál kisebb 
memóriaegységeket nem képes azonosítani, a vectorcbool:::iterator nem lehet mutató. 
A bool" például biztosan nem használható bejáróként a vectorcbool: osztályban: 


void Kvectorsbool:£k v) 


bool" p - v.beginO; // hiba: nem megfelelő típus 
H/áno8 
j 


A különálló bitek megcímzésének módját a §17.5.3 pontban mutatjuk be. 


A könyvtárban szerepel a bitsettípus is, amely logikai értékek halmazát tárolja, a logikai hal- 
mazok szokásos műveleteivel (417.5.3). 


16.4. Tanácsok 


[II Hordozható programok készítéséhez használjuk a standard könyvtár szolgálta- 
tásait. §16.1. 

[2] Ne próbáljuk újraalkotni a standard könyvtár szolgáltatásait. §16.1.2. 

[3] Ne higgyük, hogy minden esetben a standard könyvtár jelenti a legjobb 
megoldást. 

I4] Amikor új szolgáltatásokat hozunk létre, gondoljuk végig, hogy nem valósítha- 
tók-e meg a standard könyvtár nyújtotta kereteken belül. §16.3. 

[5] Ne felejtsük, hogy a standard könyvtár szolgáltatásai az sid névtérhez tartoznak. 
§16.1.2. 

I6] A standard könyvtár szolgáltatásait a megfelelő fejállomány segítségével építsük 
be, ne használjunk közvetlen deklarációt. §16.1.2. 
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[71 Használjuk ki a kései elvonatkoztatás előnyeit. §16.2.1. 

[8] Kerüljük a kövér felületek használatát. §16.2.2. 

[9] Ha az elemeken visszafelé akarunk haladni, használjunk reverse iterator-okat 
iterator helyett. §16.3.2. 

[10] Ha iterator-t szeretnénk csinálni egy reverse iterator-ból, használjuk a baseO 
függvényt. §16.3.2. 

[11] Tárolókat referencia szerint adjunk át. §16.3.4. 

[12] Ha egy tároló elemeire akarunk hivatkozni, mutatók helyett használjunk bejáró- 
típusokat (például listcchar2::iterator). §16.3.1. 

[13] Használjunk const bejárókat, ha a tároló elemeit nem akarjuk megváltoztatni. 
§16.3.1. 

[14] Ha tartományellenőrzést akarunk végezni -— akár közvetlenül, akár közvetve —, 
használjuk az atO függvényt. §16.3.3. 

[15] Használjuk inkább a bush backO vagy a resizeO függvényt egy tárolóban, mint 
a reallocO függvényt egy tömbben. §16.3.5. 

[16] Ne használjuk egy átméretezett vector bejáróit. §16.3.8. 

[17] A bejárók érvénytelenné válását elkerülhetjük a reserveO függvény használatá- 
val. §16.3.8. 

[18] Ha szükséges, a reserveO) függvényt felhasználhatjuk a teljesítmény kiszámítha- 
tóvá tételére is. §16.3.8. 


16.5. Feladatok 


A fejezet legtöbb feladatának megoldását könnyen megtalálhatjuk, ha megnézzük a stan- 
dard könyvtár adott változatát. Mielőtt azonban megnéznénk, hogy a könyvtár készítői ho- 
gyan közelítették meg az adott problémát, érdemes saját megoldást készítenünk. 


1. C1.5.) Készítsünk egy vectorcchar? típusú objektumot, amely az ábécé betűit 
tartalmazza, sorrendben. Írassuk ki ennek a tömbnek a tartalmát előre, majd 
visszafelé. 

2. G1.5.) Készítsünk egy vectorsstring: objektumot, majd olvassuk be gyümöl- 
csök neveit a cin eszközről. Rendezzük a listát, majd írassuk ki elemeit. 

3. C1.5.) A 16.5[2] feladat vektorának felhasználásával írjunk olyan ciklust, amely 
az összes a! betűvel kezdődő nevű gyümölcsöt jeleníti meg. 

4. C1.) A 16.5[2] feladat vektorának felhasználásával írjunk olyan ciklust, amellyel 
törölhetjük az összes a!" betűvel kezdődő nevű gyümölcsöt. 

5. C1.) A 16.5[2] feladat vektorának felhasználásával írjunk olyan ciklust, amellyel 
az összes citrusfélét törölhetjük. 


9. 


10. 


11. 


12. 


13. 


14. 


15. 
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. C1.5.) A 16.512] feladat vektorának felhasználásával írjunk olyan ciklust, amely 


azokat a gyümölcsöket törli, amelyeket nem szeretünk. 


. C2.) Fejezzük be a §16.2.1 pontban elkezdett Vector, List és Itor osztályt. 
. C2.5.) Az Itor osztályból kiindulva gondoljuk végig, hogyan készíthetünk 


bejárókat előre haladó bejárásokhoz, visszafelé haladó bejárásokhoz, olyan 
tárolóhoz, amely a bejárás alatt megváltozhat, illetve megváltoztathatatlan táro- 
lóhoz. Szervezzük úgy ezeket a tárolókat , hogy a programozó mindig azt 

a bejárót használhassa, amelyik a leghatékonyabb megoldást kínálja az adott al- 
goritmus megvalósítására. A tárolókban kerüljünk minden kódismértlést. Milyen 
más bejáró-fajtára lehet szüksége egy programozónak? Gyűjtsük össze az álta- 
lunk használt megközelítés előnyeit és hátrányait. 

(C2.) Fejezzük be a §16.2.2 pontban elkezdett Container, Vector és List osztály 
megvalósítását. 

(r2.5.) Állítsunk elő 10 000 darab egyenletes eloszlású véletlenszámot a 0-1023 
tartományban és tároljuk azokat a.) a standard könyvtár vector osztályával, b.) 

a §16.5[7] feladat Vector osztályával, c.) a §16.5[9] feladat Vector osztályával. 
Mindegyik esetben számoljuk ki a vektor elemeinek számtani közepét (mintha 
még nem tudnánk). Mérjük a ciklusok lefutásának idejét. Becsüljük meg vagy 
számoljuk ki a háromféle vektor memória-felhasználását, és hasonlítsuk össze 
az értékeket. 

(1.5.) Írjunk egy bejárót, amely lehetővé teszi, hogy a §16.2.2 pontban bemuta- 
tott Vector osztályt a §16.2.1 pontban használt tároló stílusában kezeljük. 

(C"1.5.) Származtassunk egy osztályt a Container-ből, amely lehetővé teszi, hogy 
a §16.2.1 vektorát a 16.2.2 pontban bemutatott tárolóstílusban használjuk. 

(2.) Készítsünk olyan osztályokat, amelyek lehetővé teszik, hogy a §16.2.1 és 

a §16.2.2 Vector osztályait szabványos tárolókként használjuk. 

(2) Írjunk egy létező (nem szabványos, nem tankönyvi példa) tárolótípushoz 
egy olyan sablont, amely ugyanazokkal a tagfüggvényekkel és típus tagokkal 
rendelkezik, mint a szabványos vector. Az eredeti tárolótípust ne változtassuk 
meg. Hogyan tudjuk felhasználni azokat a szolgáltatásokat, amelyeket a nem 
szabványos vektor megvalósít, de a vector nem? 

(C1.5) Gondoljuk végig, hogyan viselkedik a §16.3.6 pontban bemutatott 
duplicate elementsŐ függvény egy olyan vectorcstring: esetében, melynek 
három eleme: ne tedd ezt. 


1 / 


Szabványos tárolók 


, Itt az ideje, hogy munkánkat 
végre szilárd elméleti 
alapokra helyezzük." 

(Sam Morgan) 


Szabványos tárolók s Tárolók és műveletek - áttekintés s Hatékonyság "s Ábrázolás s Meg- 
kötések az elemekre s Sorozatok s vector e list s degue s Átalakítók s stack 
e gueue s priority gueue s Asszociatív tárolók e map s Összehasonlítások s multimap , 
set e multiset s , Majdnem-tárolók" e bitset s Tömbök s Hasító táblák s A hash map egy 
megvalósítása e Tanácsok s Gyakorlatok 


17.1. A szabványos tárolók 


A standard könyvtár kétféle tárolót tartalmaz: sorozatokat (seguences) és asszociatív tároló- 
kat (associative container). A sorozatok mindegyike nagyon hasonlít a vector tárolóra 
(§16.3). Ha külön nem említjük, ugyanazok a tagtípusok és függvények használhatók ezek- 
re is, mint a vektorokra, és eredményük is ugyanaz lesz. Az asszociatív tárolók ezen kívül 
lehetőséget adnak az elemek kulcsokkal történő elérésére is (§3.7.4). 
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A beépített tömbök (45.29), a karakterláncok (20. fejeze), a valarray osztály (422.4) és 
a bitset (bithalmaz) típusok szintén elemek tárolására szolgálnak, így ezeket is tárolóknak 
tekinthetjük. E típusok azonban mégsem tökéletesen kidolgozott, szabványos tárolók. Ha 
a standard könyvtár elvárásainak megfelelően próbálnánk meg elkészíteni őket, akkor el- 
sődleges céljukat nem tudnák maradéktalanul elérni. A beépített tömböktől például nem 
várhatjuk el, hogy egyszerre tartsák nyilván saját méretüket és ugyanakkor teljesen össze- 
egyeztethetőek maradjanak a C tömbökkel. 


A szabványos tárolók alapötlete, hogy logikailag felcserélhetőek legyenek minden értelmes 
helyzetben. Így a felhasználó mindig szabadon választhat közülük, az éppen használni kí- 
vánt műveletek, illetve a hatékonysági szempontok figyelembe vételével. Ha például gyak- 
ran kell elérnünk elemeket valamilyen kulcsérték segítségével, akkor a map (§17.4.1) táro- 
lót használjuk. Ha legtöbbször a szokásos listaműveletekre van szükségünk, akkor a list 
(§17.2.2) a megfelelő osztály. Ha sokszor kell hozzáfűznünk elemeket a tároló végéhez, 
vagy éppen el kell onnan távolítanunk elemeket, akkor a degue (kétvégű sor, §17.2.3), 
a stack (§17.3.1D vagy a gueue (§17.3.2) nyújtja a legtöbb segítséget. Ezeken kívül maga 
a programozó is kifejleszthet olyan tárolókat, melyek pontosan illeszkednek a szabványos 
tárolók által kínált keretrendszerbe (417.6). Leggyakrabban a vector osztályt fogjuk használ- 
ni, mert ennek előnyeit rengeteg felhasználási területen kiaknázhatjuk. 


Az ötlet, hogy a különböző jellegű tárolókat — vagy még általánosabban, az összes informá- 
cióforrást — egységes formában kezeljük, elvezet minket az általánosított (generikus) prog- 
ramozás fogalmához (42.7.2, §3.8). Ezt a szemléletmódot követve a standard könyvtár na- 
gyon sok általános algoritmust biztosít (18. fejezet), melyek megkímélik a programozót 
attól, hogy közvetlenül az egyes tárolók részleteivel foglalkozzon. 


17.1.1. Műveletek - áttekintés 


Ebben a pontban felsoroljuk azokat az osztálytagokat, amelyek minden, vagy majdnem 
minden tárolóban megtalálhatók. Ha részleteket szeretnénk megtudni, nézzük meg a meg- 
felelő fejállományt (cvector:, clistz, cmap: stb, §16.1.2). 
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Típusok (816.3.1) 











value type 
allocator. tybe 
size type 
difference type 
iterator 

const iterator 
reverse iterator 


const reverse iterator 


reference 

const reference 
key. type 
mapped type 


key compare 


Az elemek típusa. 

A memóriakezelő típusa. 

Típus az indexeléshez, elemszámláláshoz stb. 
A bejárók közötti különbség típusa. 

Úgy viselkedik, mint a value type" típus. 

A const value type?" megfelelője. 

A tároló elemeit fordított sorrendben látjuk, 
egyébként a value type" megfelelője. 

A tároló elemeit fordított sorrendben látjuk; 

a const value type" típushoz hasonlít. 

Olyan, mint a value typed . 

Olyan, mint a const value typed . 

A kulcs típusa (csak asszociatív tárolókhoZ). 
A mapped value típusa Ccsak asszociatív 
tárolókhoz). 

Az összehasonlítási szempont típusa (csak asszoci- 
atív tárolókhoz). 
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A tárolót tekinthetjük elemek sorozatának, akár abban a sorrendben, amelyet a tároló bejáró- 
ja meghatároz, akár ellenkező irányban. Egy asszociatív tároló esetében a sorrendet a tároló 
összehasonlítási szempontja határozza meg (ami alapértelmezés szerint a c műveleD. 








Bejárók (816.3.2) 
beginŐ Az első elemre mutat. 
endO Az utolsó utáni elemre mutat. 
rbeginŐ Visszafelé haladó felsorolás esetén az első elemre 
mutat. 
rendO Visszafelé haladó felsorolás esetén az utolsó utáni 
elemre mutat. 
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Néhány elemet közvetlenül is elérhetünk: 





Hozzáférés elemekhez (816.3.3) 








JrontO Az első elem. 

backO Az utolsó elem. 

[] Indexelés, ellenőrzés nélküli hozzáférés. (Listák- 
nál nem használható.) 

atO Indexelés, ellenőrzött változat. (Listáknál nem 


használható.) 











A vektorok (vector) és a kétvégű sorok (degue) olyan hatékony műveleteket is biztosítanak, 
amelyek az elemek sorozatának végén (back) végeznek módosításokat. A listák (/isD és 


a kétvégű sorok (degue) az ezekkel egyenértékű műveleteket az elemsorozatok elején 
(ronp is képesek elvégezni: 





Verem- és sorműveletek (816.3.5, 817.2.2.2) 








bush backO Elem beszúrása a tároló végére. 

bop. backO Elem eltávolítása a tároló végéről. 

bush frontO Új első elem beillesztése (csak listákhoz és kétvé- 
gű sorokhoZ). 

bop frontO Az első elem eltávolítása (csak listákhoz és kétvé- 


gű sorokhoZ). 








A tárolók lehetővé teszik a listaműveletek használatát is: 





Listaműveletek (816.3.6) 








insert(p,x) x beillesztése 5 elé. 

insert(p,n,x) x elem n darab másolatának beillesztése b elé. 
insert(p, first, las) Elemek beszúrása a [/irst: last tartományból a b elé. 
erase(p) A p helyen lévő elem eltávolítása. 

erase(first, last) A [/irst.: last tartomány törlése. 


clearO Az összes elem törlése. 
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Minden tárolóban találhatunk az elemek számával kapcsolatos műveleteket, illetve néhány 
egyéb függvényt is: 

















További műveletek (816.3.8, 816.3.9, 816.3.10) 

síze0 Az elemek száma. 

emptyO Üres a tároló? 

max sizeO A legnagyobb lehetséges tároló mérete. 

capacityO A vector számára lefoglalt terület mérete (csak 
vektorokhoZ). 

reserveO Memóriafoglalás a későbbi növelések gyorsításá- 
hoz (csak vektorokhoZ). 

resizeO) A tároló méretének módosítása (csak vektorok- 
hoz, listákhoz és kétvégű sorokhoz). 

swapO Két tároló elemeinek felcserélése. 

get allocatorO A tároló memóriafoglalójának lemásolása. 

-- Megegyezik a két tároló tartalma? 

7 Különbözik a két tároló tartalma? 

z Az egyik tároló ábécésorrendben megelőzi 
a másikat? 

A tárolók számos konstruktort, illetve értékadó operátor biztosítanak: 








Konstruktorok stb. (816.3.4) 





containerŐ Üres tároló. 

container(n) n darab elem, alapértelmezett értékkel (asszociatív 
tárolókhoz nem használható). 

containe(n,x) x elem n példányából készített tároló (asszociatív 
tárolókhoz nem használható). 

container(first, las) A kezdőelemek a (first:last/ tartományból 
származnak. 

container(x) Másoló konstruktor. A kezdeti elemeket az x táro- 


ló elemei adják. 
-containerŐ A tároló és összes elemének megsemmisítése. 
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Értékadások (§16.3.4) 








operator(x) Másoló értékadás. Az elemek az x tárolóból 
származnak. 

assign(n,x) x elem n példányának beillesztése a tárolóba 
(asszociatív tárolóknál nem használható). 

assign(first las) Értékadás a [/irst:lastl tartományból. 











Az asszociatív tárolók lehetővé teszik az elemek kulcs alapján történő elérését: 











Asszociatív műveletek (817.4.1) 

operatorl I(k) A k kulcsú elem elérése (egyedi kulccsal rendel- 
kező tárolókhozZ). 

Jjind(k) k kulccsal rendelkező elem keresése. 

lower. bound(k) Az első k kulcsú elem megkeresése. 

upper. bound(k) Az első olyan elem megkeresése, melynek kulcsa 
nagyobb, mint k. 

egual range(k) A k kulcsú elemek alsó és felső határának 
megkeresése. 

key compO A kulcs-összehasonlító objektum másolata. 

value compO A mapped value értékeket összehasonlító objek- 
tum másolata. 











Ezen általános műveleteken kívül a legtöbb tároló néhány egyedi műveletet is biztosít. 
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17.1.2. Tárolók -— áttekintés 


A szabványos tárolókat (container) az alábbi táblázat foglalja össze: 























A szabványos tárolók műveletei 
[] Lista- Műveletek Műveletek  Bejárók 
műveletek a tároló a tároló vé- 
elején gén (verem 
műveletek) 
§16.3.3 §16.3.6 417.2.2.2 §16.3.5 §19.2.1 
§17.4.1.3  §20.3.9 420.3.9 420.3.12 
vector konstans  O0(1-r konstanst " Közvetlen 
list konstans konstans konstans Kétirányú 
degue konstans  O(n konstans konstans Közvetlen 
stack konstans 
gueue konstans konstans 
briority gueue OCog(m)  Odog(n)) 
map OCog(n))  Odog(n)r Kétirányú 
multimap OCog(n)r Kétirányú 
set OCog(n)r Kétirányú 
multiset OCog(n)r Kétirányú 
string konstans  O(ndt O(n)r konstanst " Közvetlen 
array konstans Közvetlen 
valarray konstans Közvetlen 
bitset konstans 











Az Elérés oszlopban a Közvetlen azt jelenti, hogy az elemek tetszőleges sorrendben elérhe- 
tők (közvetlen elérés, random access), a Kétirányú esetében pedig kétirányú (bidirectional) 
soros hozzáférésű bejárókat használhatunk. A kétirányú bejárók műveletei részhalmazát 
képezik a közvetlen elérésűek műveleteinek (419.2.1. 


A táblázat további elemeiből az adott művelet hatékonyságára következtethetünk. A kons- 
tans érték azt fejezi ki, hogy az adott művelet végrehajtási ideje nem függ a tárolóban tárolt 
elemek számától. A konstans időigény egy másik szokásos jelölése O(1). Az O(n) érték azt 
fejezi ki, hogy a számítási idő arányos a feldolgozott elemek számával. A - jelölést azokban 
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az esetekben használtuk, ahol időnként jelentős mennyiségű többletterhelés is előfordul- 
hat. Egy elem beszúrása egy listába például mindig ugyanannyi ideig tart, így a megfelelő 
helyen a konstans értéket olvashatjuk. Ugyanez a művelet a vector esetében a beszúrási 
pont után álló összes elem áthelyezésével jár, így ott az O(n) érték szerepel. Sőt, időnként 
az összes elemet (tehát a beszúrási pont előttieket is) át kell helyezni, ezért a - jelet is meg- 
adtuk. A nagy 0" (ordo) egy hagyományos jelölésmód, a - jelet csak azért használtam, 
hogy kiegészítő információt adjak azoknak a programozóknak, akik az átlagos teljesítmény 
mellett a művelet idejének megjósolhatóságára is hangsúlyt helyeznek. Az O(1- jelölés ha- 
gyományos jelentése , amortizált lineáris idő" (amortized linear time, vagyis kb. ,többlet- 
terhet jelentő, egyenes arányosságban növekvő idő"). 


Természetesen, ha a ,konstans" egy nagyon hosszú időtartamot jelent, akkor ez nagyobb 
lehet, mint az elemek számával egyenesen arányos időigény. Nagy adatszerkezetek eseté- 
ben azonban a konstans jelentése mégis , olcsó", az O(n) jelentése pedig , drága", míg az 
Odogn)) időt tekinthetjük , elég olcsónak". Még viszonylag nagy n értékek esetén is, az 
Odog(n)) közelebb áll a konstanshoz, mint az O(mJ-hez. Azoknak a programozóknak, 
akiknek programjaik , költségeivel" komolyan foglalkozniuk kell, ennél alaposabb ismere- 
tekre is szükségük van. Tisztában kell lenniük azzal, mely elemek figyelembe vételével ala- 
kul ki n értéke. Olyan alapművelet szerencsére nincs, melyet , nagyon drágának" nevezhet- 
nénk, ami O0(n"n) vagy még jelentősebb időigényt jelentene. 


A string kivételével az itt közölt költségértékek megfelelnek a C--4 szabvány elvárásainak. 
A string típusnál szereplő becslések saját feltételezéseim. 


A bonyolultságnak, illetve az időigénynek ezen mérőszámai a felső határt jelentik. Szere- 
pük abban áll, hogy a programozó megtudhatja belőlük, mit várhat el az adott szolgáltatás- 
tól. Természetesen a konkrét megvalósítások készítői igyekeznek a lényeges helyeken 
ezeknél jobb megoldást biztosítani. 


17.1.3. Ábrázolás 


A szabvány nem ír elő semmilyen egyedi ábrázolási módot egyik tároló esetében sem. 
A szabvány csak a tároló felületét írja le, illetve néhány , bonyolultsági" követelményt hatá- 
roz meg. Az egyes nyelvi változatok készítői maguk választhatják meg a legmegfelelőbb és 
gyakran nagyon jól optimalizált megvalósítási módot, amely kielégíti az általános követel- 
ményeket. A tárolókat általában olyan adatszerkezet segítségével hozzák létre, amely az 
elemek elérését biztosító azonosító mellett a méretre és kapacitásra vonatkozó információ- 
kat is nyilvántartja. A vector esetében az elemek adatszerkezete leggyakrabban egy tömb: 


vektor: 


méret 
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ábrázolás aA 





elemek tartalék hely 








A list megvalósításának legegyszerűbb eszköze a láncolás, ahol az elemek egymásra mutatnak: 


list: 





ábrázolás 




















elemek: ő ——m 





























A map leggyakoribb megvalósítása a (kiegyensúlyozott) bináris fa, ahol a csúcsok vagy más 
néven csomópontok (kulcs, érték) párokat jelölnek ki: 


map: 


(kulcs, érték) párok: 





ábrázolás 











SES CSÚCS 
JERSa ésíjés 



































Fe 























A string megvalósítására a §11.12 pontban adtunk egy ötletet, de elképzelhetjük tömbök so- 
rozataként is, ahol minden tömb néhány karaktert tárol: 


string: 














ábrázolás SÉG e 





részlánc-leírók 


részláncok: 
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17.1.4. Megkötések az elemekre 


A tárolóban tárolt elemek a beillesztett objektumok másolatai, így ahhoz, hogy egy objek- 
tum bekerülhessen a tárolóba, olyan típusúnak kell lennie, amely lehetővé teszi, hogy a tá- 
roló másolatot készítsen róla. A tároló az elemeket egy másoló konstruktor vagy egy érték- 
adás segítségével másolhatja le. A másolás eredményének mindkét esetben egyenértékűnek 
kell lennie az eredeti objektummal. Ez nagyjából azt jelenti, hogy minden elképzelhető 
egyenlőségvizsgálat azonosnak kell, hogy minősítse az eredeti és a másolt objektumot. 
Az elemek másolásának tehát úgy kell működnie, mint a beépített típusok (köztük a muta- 
tók) szokásos másolásának. Az alábbi értékadás például nagy lépést jelent afelé, hogy az X 
típus egy szabványos tároló elemeinek típusa legyen: 


Xé£ X::oberator—(const X£ a) // helyes értékadó operátor 
( 


// "a! minden tagjának másolása "this-be 
return "this; 
j 
Az alábbi kódrészlet Ytípusa viszont helytelen, mert a visszatérési érték nem a szokásos és 


a jelentés sem megfelelő. 


void Y::operator-(const Yk a) // helytelen értékadó operátor 


( 


// "a! minden tagjának törlése 


j 


A szabványos tárolók szabályaitól való eltérések egy részét már a fordító képes jelezni, de 
sok esetben ezt a segítséget sem kapjuk meg, csak teljesen váratlan eseményekkel kerülünk 
szembe. Egy olyan másolási művelet például, amely kivételt válthat ki, részlegesen átmásolt 
elemet is eredményezhet. Ennek következményeképpen a tároló olyan állapotba kerül, 
amely csak jóval később okoz problémákat. Az ilyen másolási műveletek tehát már önma- 
gukban is rossz tervezés következményei (414.4.6.1). 


Ha az elemek másolása nem lehetséges, megoldást az jelenthet, ha a tárolóban konkrét ob- 
jektumok helyett azokra hivatkozó mutatókat helyezünk el. Ennek legnyilvánvalóbb pél- 
dája a többalakú (polimorf) típusok esete (42.5.4, §12.2.69. Ha a többalakúság lehetőségét 
meg akarjuk őrizni, akkor a vectorcShape? helyett például a vectorcShape?: osztályra lesz 
szükségünk. 
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17.1.4.1. Összehasonlítások 


Az asszociatív tárolók megkövetelik, hogy elemeiket össze lehessen hasonlítani. Ugyanez 
elmondható más tárolók néhány műveletéről is (például a rendező eljárásokról, mint 
a sortO). Alapértelmezés szerint a sorrend meghatározására a £ operátort használjuk. Ha ez 
az adott esetben nem használható, akkor a programozónak valamilyen más megoldást kell 
találnia (417.4.1.5, §18.4.29. A rendezési szempontnak szigorúan megengedőnek kell lennie 
Cstrict weak ordering), ami lényegében azt jelenti, hogy a , kisebb mint" és , egyenlő" műve- 
letnek is tranzitívnak kell lennie. Vegyük például a következő cmp rendezést: 


1. cmp(x,x) mindig hamis. 

2. Ha cmpCx,y) és cmp(y,2), akkor cmp(x, 2). 

3. Határozzuk meg az egyenlőség eguiw(x,y) műveletét a következő kifejezéssel: 
K(cmpCx,y) I lemp(y,x)). Így, ha eguiu(x,y) és eguiv(y,z), akkor egui(x, 2). 


Ennek megfelelően a következőket írhatjuk: 


templatezclass Ran: void sort(Ran first, Ran last; // a £ használata az 
// összehasonlításra 
templatexclass Ran, class Cmp: void sort(Ran first, Ran last, Cmp cmp); 
// a cmp használata 


Az első változat a — operátort használja, míg a második a programozó által megadott cmp 
rendezést. Az előző fejezet gyümölcsöket tartalmazó tárolójának esetében például szüksé- 
günk lehet egy olyan rendező eljárásra, amely nem különbözteti meg a kis- és nagybetűket. 
Ezt úgy érhetjük el, hogy létrehozunk egy függvényobjektumot (function objecb) (411.9, 


§18.4), amely egy siring-párra elvégzi az összehasonlítást: 


class Nocase ( /7 kis- és nagybetűket nem megkülönböztető karakterlánc- 
// összehasonlítás 
bublic: 
bool operatorO(const stringk , const stringé ) const; 
h 


bool Nocase::operatorO(const string x, const stringít y) const 
// igazat ad vissza, ha x ábécésorrendben megelőzi y-t; a kis- és nagybetűk közötti 
// különbség nem számít 
( 
string::const iterator p - x.beginO; 
string::const iterator g - y.beginO; 
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while (p!-x.endO ££ g/-y.endO kk toupperCp)--toupberC9)) ( 
tAD; 


44g; 
) 

if (p —— x.endO) return g !- y.endO; 
if (g -— y.endO) return false; 

return toupberCp) c toupperC a); 


A sort függvényt ezután meghívhatjuk ezzel a rendezési szemponttal. Például az alábbi so- 
rozatból kiindulva: 


fruit: 
alma körte Alma Körte citrom 


A sort(fruit.beginO, fruit.end, NocaseO) rendezés eredménye a következő lesz: 


fruit: 
Alma alma citrom Körte körte 


Ugyanakkor az egyszerű sort(fruit.beginO, fruit.endO) a következő eredményt adná (felté- 
telezve, hogy olyan karakterkészletet használunk, ahol a nagybetűk megelőzik a kisbetűke0: 


fruit: 
Alma Körte alma citrom körte 


Vigyázzunk rá, hogy a c operátor a C stílusú karakterláncoknál (tehát a char" típusnál) nem 
ábécésorrend szerinti rendezést jelent (413.5.29. Ennek például az a következménye, hogy 
az olyan asszociatív tárolók, melyeknek kulcsa C stílusú karakterlánc, nem úgy működnek, 
mint ahogy azt első ránézésre gondolnánk. Ezen kellemetlenség kijavításához egy olyan c 
operátort kell használnunk, amely tényleg ábécésorrend szerinti összehasonlítást végez: 


struct Cstring less f 
bool operator (const char? p, const char? ag) const ( return strcmp(p, a) 2O; ) 


J; 


mapcchar", int, Cstring lessz m; // const char" kulcsok összehasonlítására a strempO 
// függvényt használó asszociatív tömb 
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17.1.4.2. További relációs műveletek 


A tárolók és az algoritmusok alapértelmezés szerint a c műveletet használják, amikor az 
elemek között sorrendet kell megállapítaniuk. Ha ez az alapértelmezés nem felel meg 
a programozónak, akkor új összehasonlítási szempontot is megadhat. Az egyenlőségvizsgá- 
lat műveletét viszont nem adhatjuk meg közvetlenül. Ha van egy sorrend-meghatározó függ- 
vényünk (például a cmp), akkor az egyenlőséget két sorrendvizsgálattal állapíthatjuk meg: 


if(x -—y) // megadott felhasználói összehasonlítás esetén nem használatos 


if dcmp(x,y) k.k Icmp(y,x)) // a felhasználói cmp összehasonlítás esetén használatos 


Ez a lehetőség megkímél minket attól, hogy minden asszociatív tároló és számos algoritmus 
esetében külön paraméterként adjuk át az egyenlőségvizsgáló eljárást. Első ránézésre azt 
mondhatnánk, hogy ez a megoldás nem túl hatékony, de a tárolók rendkívül ritkán vizsgál- 
ják elemeik egyenlőségét, és ilyenkor is általában elegendő egyetlen cmpO hívás. 


A , kisebb mint" (alapértelmezés szerint c ) művelettel végzett egyenértékűség-vizsgálat 
gyakorlati okokból is hasznosabb lehet, mint az , egyenlő" (--) használata. Az asszociatív 
tárolók (417.4) például a / (cmp(x,y) I lcmp(y,x)) egyenértékűség-vizsgálattal hasonlítják 
össze a kulcsaikat. Az egyenértékű kulcsok nem feltétlenül egyenlők. Egy olyan multimap 
(§17.4.2) például, amelynek sorrend-meghatározó függvénye nem különbözteti meg a kis- 
és nagybetűket, a Last, last, IAst, és lasTkarakterláncokat egyenértékűnek fogja minősíteni, 
annak ellenére, hogy az -— operátor különbözőnek tartja azokat. Így tehát lehetőségünk 


nyílik arra, hogy a számunkra lényegtelen különbségektől a rendezésben eltekintsünk. 


A c és az —— operátor segítségével a többi szokásos összehasonlító műveletet könnyen 
definiálhatjuk. A standard könyvtár az std::rel ops névtérben adja meg ezeket és a cutility: 
fejállomány segítségével használhatók: 


templatexclass T: bool rel ops::operator!l-(const Tk x, const Ik y) ( return K(x-——y); ) 
templatexclass T: bool rel ops::operator:(const Ik x, const Ik y) ( return yxXx; ) 

templatexclass T: bool rel ops::operatorc-(const Ik x, const Ik y) ( return Kyox); ) 
templatexclass T: bool rel ops::operator:—(const Ik x, const Ik y) ( return K(Xx2y); ) 


A rel ops névtér alkalmazása biztosítja, hogy az operátorokat könnyen elérhetjük, amikor 
szükség van rájuk, viszont meghatározásuk nem történik meg , titokban", ha explicit nem 
kérjük a névtér használatát. 


void JO 
( 
using namespace std; 
// a 17, - stb. alapértelmezés szerint nem jön létre 


J 
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void g0 
( 


using namespace sid; 
using namespace std::rel. ops; 
// a 17, 2 stb. alapértelmezés szerint létrejön 


J 


A /-, stb. operátorokat nem az sid névtér írja le, mert nem mindig van rájuk szükség, és bizo- 
nyos esetekben meghatározásuk meg is változtatná a felhasználó programjának működését. 
Például, ha egy általános matematikai könyvtárat akarunk készíteni, akkor valószínűleg a sa- 
ját relációs műveleteinkre lesz szükségünk és nem a beépített függvényekre. 


17.2. Sorozatok 


A sorozatok körülbelül úgy néznek ki, mint a korábban (§16.3) bemutatott vector. A stan- 
dard könyvtár által biztosított alapvető sorozatok a következők: 


vector list degue 


Ezekből származnak -— a megfelelő felület kialakításával — az alábbi tárolók: 


stack gueue priority gueue 


Ezeket a sorozatokat tároló-átalakítóknak (container adapter), sorozat-átalakítóknak 
(seguence adapter) vagy egyszerűen átalakítóknak (adapter, §17.3) nevezzük. 


17.2.1. A vector 


A szabványos vector osztállyal a §16.3 pontban már részletesen foglalkoztunk. Az előzetes 
memóriafoglalás (reserve) lehetősége kizárólag a vektorokra jellemző. Az indexelés a / / 
operátorral ellenőrizetlen adatelérést jelent. Ha ellenőrzött hozzáférést szeretnénk, használ- 
juk az atÓ függvényt (416.3.3), egy ellenőrzött vektort (§3.7.2) vagy egy ellenőrzött bejárót 
(§19.3). A vector osztályokban közvetlen elérésű (random-access) bejárókat (419.2.1) hasz- 
nálhatunk. 
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17.2.2. A list 


A lista egy olyan sorozat, amely elemek beszúrására és törlésére a legalkalmasabb. A vector 
Cés a degue, §17.2.3) osztállyal összehasonlítva az indexelés fájdalmasan lassú lenne, így 
meg sem valósították a /ist tárolóban. Ennek következménye, hogy a ist csak kétirányú 
(bidirectional) bejárókat (419.2.1) biztosít, közvetlen elérésűeket nem használhatunk. A list 
osztályt ezek alapján valamilyen kétirányú láncolt listával szokás megvalósítani (417.8[16D. 


A lista mindazon tagtípusok és tagfüggvények használatát lehetővé teszi, melyet a vektor 
(§16.3) esetében megtalálunk, kivéve az indexelést, a capacityO és a reserveO függvényeket: 


template class T, class A - allocatorsT: : class std-::list f 

bublic: 
// a vector-éhoz hasonló típusok és műveletek, kivéve: ( ]J, atO, capacityO, és reserveO 
Mea 

J; 


17.2.2.1. Áthelyezés, rendezés, összefésülés 


Az általános sorozat-műveletek mellett a /ist számos, kifejezetten a listákhoz készített mű- 
veleteket kínál: 


template class T, class A - allocatorsT: : class list f 
bublic: 
ÚT ts 


// kifejezetten listákhoz készített műveletek 


void splice(iterator pos, listít x); // x minden elemének áthelyezése 

// a listában levő pos elé, másolás nélkül 
void splice(iterator pos, listk x, iteratorpb); — // ?p áthelyezése x-ből 

// a listában levő pos elé, másolás nélkül 
void splice(iterator pos, listg x, iterator first, iterator last); 


void merge(listk ); // rendezett listák összefésülése 
template Cclass Cmp: void merge(listk, Cmp); 


void sortO; 
template cclass Cmp? void sort(Cmp); 


Mas 
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Ezek a listaműveletek szabilak (stable), ami azt jelenti, hogy az egyenértékű értékkel ren- 
delkező elemek egymáshoz viszonyított (relatív) sorrendje nem változik meg. 


A §16.3.6 pontban példaképpen a ffruit tárolón végeztünk műveleteket. Azok a feladatok 
változtatás nélkül elvégezhetők akkor is, ha a fruit történetesen egy lista. Ezenkívül az 
egyik lista elemeit egyetlen splice művelettel át is helyezhetjük egy másik listába. Induljunk 
ki az alábbi listákból: 


fruit: 
alma körte 


citrus: 
narancs grapefruit citrom 


A következő művelettel tudjuk a narancs elemet áthelyezni a citrus listából a fruit listába: 


listsstring:::iterator p - find ifffruit.beginO fruit.endO, initialC Rk"); 
Jruit.splice(p, citrus, citrus.begin ; 


A művelet kiveszi a citrus első elemét, majd beilleszti ezt az elemet a fruit tároló első k be- 
tűvel kezdődő eleme elé. Az eredmény tehát a következő: 


fruit: 
alma narancs körte 


Citrus: 
grapefruit citrom 


Jegyezzük meg, hogy a splice0 nem készít másolatokat az elemekről úgy, mint az insertŐ 
(§16.3.0), csak a listák adatszerkezetét rendezi át a feladatnak megfelelően. 


A spliceO segítségével nem csak egyetlen elemet, hanem tartományokat, vagy akár teljes lis- 
tákat is áthelyezhetünk: 


Jruit.splice(fruit.beginO, citrus); 


Eredménye: 


JÍruit: 
grapefruit citrom alma narancs körte 


citrus: 
Lxüres2 
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A splice függvény minden változatának a második paraméterben meg kell adnunk azt a /isz 
objektumot, amelyből az elemeket át kell helyezni. Ez teszi lehetővé, hogy az eredeti listá- 
ból töröljük az elemet. Egy bejáró erre önmagában nem lenne alkalmas, hiszen egy konk- 
rét elemre mutató bejáróból semmilyen általános módszerrel nem lehet megtudni, hogy az 
adott elem éppen melyik tárolóban található (§18.09. 


Természetesen, a bejáró-paraméternek olyan érvényes bejárót kell tartalmaznia, amely 
a megfelelő listához kapcsolódik. Tehát vagy a list egyik elemére kell mutatnia, vagy a lis- 
ta endŐ függvényének értékét kell tartalmaznia. Ha ez nem így van, akkor az eredmény 
nem meghatározható és általában végzetes problémákat okoz: 


listsstring:::iterator p -— find ifffruit.beginO fruit.endO, initial Rk); 

Jfruit.splice(p, citrus, citrus.begin 0);  // rendben 

Jruit.splice(p, citrus, fruit.beginO);  — // hiba: fruit.beginO nem mutat citrus-ban levő elemre 
citrus.splice(p, fruit fruit.begin0);  // hiba: b nem mutat citrus-ban levő elemre 


Az első splice0O helyes még akkor is, ha a citrus tároló üres. 


A mergeŐ két rendezett listát egyesít (fésül össze). Az egyik listából törli az elemeket, mi- 
közben a másikba beszúrja azokat, a rendezés megőrzésével. 


JT: 


alma birsalma körte 


J2: 


citrom grapefruit narancs lime 


Ez a két lista az alábbi programrészlettel rendezhető és fűzhető össze: 


JI.sortO; 
f2.sortO; 
JI .merge(f2; 


Az eredmény a következő lesz: 


JT: 


alma birsalma citrom grapefruit körte lime narancs 


J2: 


xüres2 


Ha az összefésült listák valamelyike nem volt rendezett, a mergeO akkor is olyan listát ered- 
ményez, amelyben a két lista elemeinek uniója szerepel, de az elemek helyes sorrendje 
nem biztosított. 
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A spliceO függvényhez hasonlóan a mergeO sem másolja az elemeket, hanem a forráslistá- 
ból kiveszi, majd a céllistába beilleszti azokat. Az x.merge(y) függvény meghívása után az 
)y lista üres lesz. 


17.2.2.2. Műveletek a lista elején 


A lista első elemére vonatkozó műveletek azoknak a minden sorozatban megtalálható eljá- 
rásoknak a párjai, melyek az utolsó elemre hivatkoznak (§16.3.09: 


template cclass T, class A - allocatorsT: : class list f 
bublic: 
s 


// hozzáférés elemekhez 


reference frontO; // hivatkozás az első elemre 
const reference frontO const; 


void push front(const TE); // új első elem hozzáadása 
void pop frontO; // első elem eltávolítása 
1/48 


A tároló első elemének neve front. A list esetében a front fejelem műveletei ugyanolyan ha- 
tékonyak és kényelmesek, mint a sorozat végét kezelő függvények (§16.3.5). Ha mi dönt- 
hetünk, akkor érdemesebb az utolsó elemet használni, mert az így megírt programrészletek 
a vector és a list számára is megfelelőek. Így ha csak egy kicsi esély is van arra, hogy az ál- 
talunk listára használt algoritmust valamikor - általános eljárásként — más tárolótípusokra is 
alkalmazzuk, akkor mindenképpen az utolsó elem műveleteit használjuk, hiszen ezek jóval 
szélesebb körben működőképesek. Itt is ahhoz a szabályhoz kell igazodnunk, miszerint 
a lehető legnagyobb rugalmasság elérése érdekében érdemes a lehető legkisebb művelet- 
halmazt használnunk egy feladat elvégzéséhez (§17.1.4.1). 


17.2.2.3. További műveletek 


Az elemek beszúrása és törlése rendkívül hatékony művelet a /ist tárolóban. Ez természete- 
sen arra ösztönzi a programozókat, hogy listát használjanak, ha programjaikban az ilyen 
műveletek gyakoriak. Ezért fontos, hogy az elemek közvetlen törlésére általános, szabvá- 
nyos módszereket adjunk: 
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template class T, class A - allocatorsT: : class list f 
bublic: 
27742 


void remove(const Id val); 
template Sclass Pred: void remove if(Pred p9; 


void unigueoO; // kétszer szereplő elemek eltávolítása -- használatával 
template class BinPred: void unigue(BinPred b); // kétszer szereplő elemek 


// eltávolítása b használatával 


void reverseO; // az elemek sorrendjének megfordítása 


); 


Például tegyük fel, hogy adott az alábbi lista: 


JÍruit: 
alma narancs grapefruit citrom narancs görögdinnye körte birsalma 


Ekkor a , narancs" értékkel rendelkező elemeket a következő paranccsal távolíthatjuk el: 


JÍruit.remove( "narancs "); 


Az eredmény tehát: 


JÍruit: 
alma grapefruit citrom görögdinnye körte birsalma 


Gyakran bizonyos feltételt kielégítő elemeket szeretnénk törölni, nem csak egy adott érték- 
kel rendelkezőket. A remove iffüggvény pontosan ezt a feladatot hajtja végre. A követke- 
ző utasítás például az összes 9" betűvel kezdődő gyümölcsnevet törli a fruit listából: 


Jruit.rremove ifinitialCg); 


A függvény lefutása után a fruit a következőképpen néz ki: 


JÍruit: 
alma citrom körte birsalma 


A törléseknek gyakran az az oka, hogy meg szeretnénk szüntetni az ismétlődéseket. 
A unigueO függvény ezzel a céllal szerepel a /ist osztályban: 


JÍruit.sortO; 
JÍruit.unigueO; 
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A rendezésre azért van szükség, mert a unigueO csak azokat az ismétlődéseket szűri ki, 
amelyeknél közvetlenül egymás után szerepel két (vagy több) azonos érték. Például ha 
a fruit lista tartalma a következő: 


alma körte alma alma körte 


akkor a fruit.unigueO hívás önmagában az alábbi eredményt adná: 


alma körte alma körte 


Ha először rendezünk, akkor a végeredmény: 


alma körte 


Ha csak bizonyos ismétlődéseket akarunk megszüntetni, akkor megadhatunk egy prediká- 
tumot (feltételt), amely meghatározza, mely ismétlődések nem kellenek. Például meghatá- 
rozhatjuk a kétoperandusú (bináris) initial2(x) predikátumot (§18.4.2), amely karakterlán- 
cokat vizsgál, és csak akkor ad igaz értéket, ha a karakterlánc x betűvel kezdődik. Tehát ha 
a következő listából indulunk ki: 


körte körte alma alma 


akkor a következő utasítással el tudjuk tüntetni az összes k" betűvel kezdődő, egymás után 
következő nevet: 


JÍruit.unigue(initial2Ck); 


Az eredmény a következő lesz: 


körte alma alma 


A §16.3.2 pontban már volt róla szó, hogy a tároló elemeit néha fordított sorrendben akar- 
juk elérni. A /isz esetében lehetőség van arra, hogy az elemek sorrendjét teljesen megfordít- 
suk, azaz az utolsó elem váljon elsővé, az első pedig utolsóvá. A reverseO függvény ezt 
a műveletet az elemek másolása nélkül valósítja meg. Vegyük a következő listát: 


JÍruit: 
banán cseresznye eper körte 
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Ekkor a fruit.reverseO hívás eredménye a következő lesz: 


JÍruit: 
körte eper cseresznye banán 


A listából eltávolított elemek teljesen törlődnek. Egy mutató törlése azonban nem jelenti azt, 
hogy maga a mutatott objektum is törlődik. Ha olyan mutatókból álló tárolót akarunk hasz- 
nálni, amely automatikusan törli a belőle kivett mutatók által mutatott objektumokat, akkor 
azt nekünk kell megírnunk (417.8[12D. 


17.2.3. A degue 


A degue egy kétvégű sort (double-ended gueue) valósít meg. Ez azt jelenti, hogy a degue 
egy olyan sorozat, amit arra optimalizáltak, hogy egyrészt mindkét végén ugyanolyan haté- 
kony műveleteket használhassunk, mint egy /ist-nél, másrészt az indexelés ugyanolyan ha- 
tékony legyen, mint a vector esetében: 


template class T, class A - allocatorsT: : class std::degue f( 

// a vector-éhoz hasonló típusok és műveletek (§16.3.3, §16.3.5, §16.3.6), kivéve: 
// capacity és reserveO) 

// a list-éhez hasonló fejelem-műveletek (§1 7.2.2.2) 

J; 


Az adatszerkezet belsejében az elemek törlése és beszúrása ugyanolyan (rossz) hatékony- 
ságú, mint a vector-nál. Ennek következtében a degue tárolót akkor használjuk, ha beszú- 
rások és törlések általában csak a végeken fordulnak elő, például egy vasútszakasz model- 
lezéséhez vagy egy kártyapakli ábrázolásához: 


deguexcar? siding no 3; 
deguezCard: bonus; 


17.3. Sorozat-átalakítók 


A vector, a listés a degue sorozatok nem építhetők fel egymásból komoly hatékonyságrom- 
lás nélkül. Ugyanakkor a verem (stack) és a sor (gueue) elegánsan és hatékonyan megva- 
lósítható e három alap-sorozattípus segítségével. Így ezt a két osztályt nem teljesen önálló 
tárolóként határozták meg, hanem az alaptárolók átalakítóiként. 
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Egy tároló átalakítója (adapter) egy leszűkített (korlátozott) felületet ad az adott tárolóhoz. 
A legszembetűnőbb, hogy az átalakítók nem biztosítanak bejárókat, mert a céljuknak meg- 
felelő felhasználáskor a leszűkített felület elegendő szolgáltatást nyújt. Azokat a módszere- 
ket, melyekkel egy tárolóból létrehozhatunk egy átalakítót, általánosan használhatjuk olyan 
esetekben, amikor egy osztály szolgáltatásait a felhasználók igényeihez szeretnénk igazíta- 


ni, az eredeti osztály megváltoztatása nélkül. 


17.3.1. A stack 


A stack (verem) tárolót a cstack: fejállomány írja le. Annyira egyszerű szerkezet, hogy le- 
írásának legegyszerűbb módja, ha bemutatunk egy lehetséges megvalósítást: 


template class T; class C - deguezT: : class std::stack f 
brotected: 

C c; 
bublic: 

typedef typename C::value type value type; 

typedef typename C::size type size type; 

typedef C container. type; 


explicit stack(const Ckg a - CO) : c(a) f ) 


bool emptyO const ( return c.emptyO; ? 
size type sizeO const f return c.sizeO; ) 


value typek topO f return c.bacRO; )? 
const value typeg topO const ( return c.backO; ) 


void push(const value typeg x) ( cpush backCx9; ) 
void popO ( c.pop. bacRkO; ) 


Vagyis a stack egyszerűen egy felület egy olyan tárolóhoz, melynek típusát sablonparamé- 
terként adjuk meg. A stack mindössze annyit tesz, hogy elrejti tárolójának nem verem stílu- 
sú műveleteit, valamint a backO, push backO, pop backO függvényeket hagyományos 
nevükön (topO, bushO, popO) teszi elérhetővé. 


Alapértelmezés szerint a szack egy degue tárolót használ elemeinek tárolására, de bármi- 
lyen sorozatot használhatunk, melyben elérhető a backO, a bush backO és a pop backO 


függvény: 


stackcchar? 51; // char típusú elemek tárolása deguecchar: segítségével 
stackc int, vectorsint: 2 s2;  / int típusú elemek tárolása vectorcsint: segítségével 
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Egy verem kezdeti feltöltéséhez felhasználhatunk egy már létező tárolót is: 


void print backwards(vectorsint:k v) 
( 
stackz int, vectorsint: 5 state(v); // kezdőállapot beállítása v segítségével 
while (state.size0) ( 
cout c£ state.topO; 


state.bopO; 


De gondoljunk rá, hogy ez a művelet a paraméterként megadott tároló elemeinek másolá- 
sával jár, így rendkívül hosszadalmas lehet. 


A veremhez az elemek tárolásához használt tároló bush backO műveletével adunk eleme- 
ket. Így a stack nem telhet meg mindaddig, amíg a tároló képes memóriát lefoglalni (me- 


móriafoglalójának segítségével, §19.4). 


Ugyanakkor a verem alulcsordulhat: 


void JO 
( 
stackcint: s; 
s.push2; 
if (s.emptyO) f // az alulcsordulás megakadályozható 
// nincs kiemelés 
, 
else ( // de nem elképzelhetetlen 
s.popO; // jó: s.size0 értéke O lesz 
s.bopO; // nem meghatározott hatás, valószínűleg rossz 
, 
J 


Jegyezzük meg, hogy a felső elem használatához nincs szükségünk a popO függvényre. 
Erre a topO utasítás szolgál, a bobO műveletre pedig akkor van szükség, ha el akarjuk távo- 
lítani a legfelső elemet. Ez a megoldás nem túlságosan kényelmetlen, és sokkal hatéko- 
nyabb, amikor a popO műveletre nincs szükség: 


void f((stackcchar-€£ 5) 

í 
if (s.topO--tc!) s popO; // nem kötelező kezdő c! eltávolítása 
Sales 

J 
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Az önállóan, teljesen kifejlesztett tárolókkal ellentétben a veremnek (és a többi tároló-átala- 
kítónak) nem lehet memóriafoglalót megadni sablonparaméterként, azt a stack megvalósí- 
tásához használt tároló saját memóriafoglalója helyettesíti. 


17.3.2. A gueue 


A cgueue? fejállományban leírt gyeue (sor) olyan felület egy tárolóhoz, amely lehetővé te- 
szi az elemek beszúrását az adatszerkezet végére, illetve kivételét a tároló elejéről: 


template class T; class C - deguezT: : class std::gueue f 
brotected: 

Ce: 
bublic: 

typedef typename C::value type value type; 

typedef typename C::size type size type; 

typedef C container. type; 


explicit gueue(const Cg a - CO) : c(a) ( ) 


bool emptyO const f return c.emptyO; ) 
size type sizeO const f return c.sizeO; ) 


value typek front ( return c.frontO; ) 
const value typeg front const ( return c. frontO; ) 


value typeg backO ( return c.backO; ) 
const value type backO const f return c.backO; ) 


void push(const value typeg x) ( cpush backCx9; ) 
void popO ( c.pop. frontO; ) 
vi 


Alapértelmezés szerint a gueuea degue tárolót használja elemeinek tárolásához, de bármely 
sorozat betöltheti ezt a szerepet, amely rendelkezik a /rontO, backO, push backO és 
bop frontO függvényekkel. Mivel a vector nem teszi lehetővé a pop frontO használatát, 
a vektor nem lehet a sor belső tárolója. 
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A sor szerkezet szinte minden rendszerben előfordul valamilyen formában. Egy egyszerű 
üzenetalapú kiszolgálót például a következőképpen határozhatunk meg: 


struct Message f 


Mék 
j; 
void server(gueueSZMessagexk ag) 
t 
while(!Ig.emptyO) ( 
Messagek m - g.frontO; — // üzenet elfogása 
m.service(); // a kérést kiszolgáló függvény meghívása 
g.popO; // üzenet törlése 
, 
J 


Az üzeneteket a pushO utasítás segítségével helyezhetjük a sorba. 


Ha az ügyfél (kliens) és a kiszolgáló (szerver) külön-külön folyamatként vagy szálként fut, 
akkor a sor-hozzáféréseket valamilyen módon össze kell hangolnunk (szinkronizálás): 


void server (gueuezMessage-£ g, Lockk lck) 


( 
while(!Ig.emptyO) ( 
Message m; 
FA LockPtr h(Ick); // zárolás az üzenet kinyerése közben (§14.4.1) 
if (g.emptyO) return; // valaki más már megszerezte az üzenetet 
m - g. frontO; 
g.bopO; 
, 
m.serviceO; // a kérést kiszolgáló függvény meghívása 
, 
J 


Az egyidejű hozzáférésnek (konkurrencia, párhuzamosság), illetve a zárolásnak (ock) még 
nincs szabványos definíciója sem a Ct4 nyelvben, sem a számítástechnika világában. Ha 
ezeket a lehetőségeket szeretnénk használni, akkor járjunk utána, hogy saját rendszerünk 
milyen lehetőségeket biztosít, és azokat hogyan érhetjük el a C-t nyelvből (§417.818]. 


17.3.3. A priority gueue 


A priority gueue Cprioritásos sor) egy olyan sor, melyben az elemek fontossági értéket kap- 
nak, és ez az érték szabályozza, hogy az elemek milyen sorrendben vehetők ki: 
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template class T, class C - vectorzT:, class Cmp - lessztypename C::value type: 2 
class std::priority gueue f 
brotected: 
LÉT Si 
Cmp cmp; 
bublic: 
typedef typename C::value type value type; 
typedef typename C::size type size type; 
typedef C container. type; 


explicit priority gueue(const Cmpk al - CmpO, const Ck a2 - CO) 

: c(a2), cmp(a1) (f make heap(c.beginO,c.endO,cmp9; ) // lásd §18.8 
template cclass In: 
briority gueued first, In last, const Cmpk - CmpO, const Cg —- CO; 


bool emptyO const ( return c.emptyO; ) 
size type sizeO const f return c.sizeO); ) 


const value typeg topO const ( return c frontO; ) 


void push(const value type ); 
void popO; 


A priority gueue-t a Cgueue? fejállomány deklarálja. 


Alapértelmezés szerint a priority gueue az elemeket egyszerűen a c operátor segítségével 
hasonlítja össze, és a top() mindig a legnagyobb elemet adja vissza: 


struct Message f 
int priority; 
bool operators(const Messagek x) const f return priority £ x.priority; ) 


Mé 


J; 


void server(priority gueuesMessage:k g, Lock lck) 


( 
whileC(!Ig.emptyO) ( 

Message m; 

( LockPtr h(Ick); // zárolás az üzenet kinyerése közben (§14.4.1) 
if (g.emptyO) return; // valaki más már megszerezte az üzenetet 
m - g.topO; 
g.DopO; 

j 

m.serviceO; // a kérést kiszolgáló függvény meghívása 
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Ez a programrészlet abban különbözik a sornál (gueue, §17.3.2) bemutatott példától, hogy 
itt az üzenetek közül a legfontosabb ( legnagyobb prioritású") kerül először feldolgozásra. 
Az nem meghatározott, hogy az azonos fontossági értékkel rendelkező elemek közül me- 
lyik jelenik meg először a sor elején. Két elem fontossága (prioritása) akkor egyezik meg, 
ha egyik sem , fontosabb" a másiknál (§17.4.1.59. 


Ha a c operátor nem felel meg céljainknak, akkor egy sablonparaméter segítségével meg- 
adhatjuk az összehasonlító műveletet. Például karakterláncokat rendezhetünk a kis- és 
nagybetűk megkülönböztetése nélkül, ha az alábbi sorban helyezzük el azokat: 


briority gueuesstring, vectorsstring:, Nocase2 bg; . // Nocase használata az 
// összehasonlításokhoz (§17.1.4.1) 


A karakterláncokat a bg.pushO utasítással tesszük be a sorba és a bg.tobO, pg.bpopO műve- 
letekkel dolgozhatjuk fel. 


Az olyan sablonokbáól létrehozott objektumok, melyeknél különböző sablonparamétereket 
használtunk, különböző típusúak (§13.6.3.1D: 


briority gueuesstringzk bg1 -pg; — // hiba: nem megfelelő típus 


Összehasonlítási szempontot megadhatunk úgy is, hogy közben nem változtatjuk meg 
a prioritásos sor típusát. Ehhez egy megfelelő típusú összehasonlító objektumot kell létre- 
hoznunk, melynek konstruktor-paraméterében megadjuk az érvényes összehasonlítási 
szempontot: 


struct String cmp ( // futási idejű összehasonlítási feltételt kifejező típus 
String cmp(Cint n — 09; // az n összehasonlítási feltétel használata 
KART 

J; 


typedef priority gueuesstring, vectorsstring:, String cmp: Pgueue; 


void ((Pgueuek pg) // a pg a String cmpO-et használja az összehasonlításokhoz 
( 

Pgueue pg2x(String cmp(nocase)); 

bag - pa2 // rendben: pa és bg2 azonos típusú, így pg most 


// a String cmp(nocase)J-t shasználja 


Az elemek rendezése némi teljesítményromlással jár, de ez egyáltalán nem jelentős. 
A priority gueue egyik hatékony megvalósítási módja a faszerkezet, mellyel az elemek egy- 
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máshoz viszonyított helyét könnyedén beállíthatjuk. Ezzel a megoldással a pushO és 
a popO művelet költsége is O(log(n)). 


Alapértelmezés szerint a priority gueue egy vector tárolót használ elemeinek nyilvántartás- 
ára, de bármely sorozattípus megfelel e célra, amely rendelkezik a frontO, push backO és 
bop backO függvényekkel, valamint lehetővé teszi közvetlen elérésű bejárók használatát. 
A prioritásos sorok leggyakrabban használt megvalósítási eszköze a heap (kupac vagy ha- 
lom, §18.8) 


17.4. Asszociatív tárolók 


Az asszociatív tömb az egyik leghasznosabb felhasználói típus. Ennek következtében az el- 
sősorban szöveg- vagy szimbólum-feldolgozásra kifejlesztett nyelvekben gyakran beépített 
típusként szerepel. Az asszociatív tömb, melynek gyakori elnevezése a map (hozzárende- 
lés, leképezés) és a dictionary (szótár) is, értékpárokat tárol. Az egyik érték a kulcs (key), 
melyet a másik érték (a hozzárendelt érték, mapped value) eléréséhez használunk. 
Az asszociatív tömböt úgy képzelhetjük el, mint egy tömböt, melynek indexe nem feltétle- 
nül egy egész szám: 


templatexciass K, class V: class Assoc f 

bublic: 
V£ operatorl ((const Kg);  // hivatkozás visszaadása a K-nak megfelelő V-re 
IT aa 


J; 


Itt a X típusú kulcs segítségével a Vtípusú hozzárendelt értéket választjuk ki. 


Az asszociatív tároló az asszociatív tömb fogalmának általánosítása. A map sablon a hagyo- 
mányos asszociatív tömbnek felel meg, ahol minden kulcsértékhez egyetlen értéket rende- 
lünk. A multimap egy olyan asszociatív tömb, amely megengedi, hogy ugyanolyan kulcs- 
értékkel több elem is szerepeljen, míg a set és a multiset olyan egyedi asszociatív tömbök, 
melyekben nincs hozzárendelt érték. 
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17.4.1. A map 


A map (kulcs érték) párok sorozata, melyben a bejegyzéseket a kulcs (key) alapján gyorsan 
elérhetjük. A map tárolóban a kulcsok egyediek, azaz minden kulcshoz legfeljebb egy ér- 
téket rendelünk hozzá. A map szerkezetben kétirányú bejárókat használhatunk (419.2.19. 


A map megköveteli, hogy a kulcsként használt típusokban a ,kisebb mint" művelet hasz- 
nálható legyen (§17.1.4.1), és ez alapján az elemeket rendezve tárolja. Ennek következté- 
ben a map bejárásakor az elemeket rendezve kapjuk meg. Ha olyan elemeink vannak, me- 
lyek között nem lehet egyértelmű sorrendet megállapítani, vagy nincs szükség arra, hogy 
az elemeket rendezve tároljuk, akkor használjuk inkább a hash map szerkezetet (§17.09. 


17.4.1.1. Típusok 


A map a tárolók szokásos típus tagjain (§16.3.1) kívül néhány, az osztály egyedi céljának 
megfelelő típust is meghatároz: 


template cclass Key, class T; class Cmp - lesszKey?, 
class A - allocators paircconst Key, T2: 2 5 
class std::map f 
public: 
// típusok 


typedef Key key type; 
typedef T mapped type; 


typedef paircconst Key, T- value type; 


typedef Cmp key compare; 
typedef A allocator. type; 


typedef typename A::reference reference; 
typedef typename A::const reference const reference; 


tybedefmegvalósítás függől iterator; 
tybedefmegvalósítás függő2 const iterator; 


typedef typename A::size type size type; 
typedef typename A::difference type difference type; 


typedef std::reverse iteratorZiterator: reverse iterator; 
typedef std::reverse iteratoráconst iterator: const reverse iterator; 


Mé 
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Jegyezzük meg, hogy a value type a map esetében a (kulcs, érték) bárt (pair) jelenti. A hoz- 
zárendelt értékek típusát a mapped type adja meg. Tehát a mab nem más, mint paircconst 
Key, mapped type: típusú elemek sorozata. Szokás szerint a konkrét bejáró-típusok az adott 
megvalósítástól függőek. Mivel a map tárolót leggyakrabban valamilyen faszerkezet segítsé- 
gével valósítják meg, a bejárók általában biztosítanak valamilyen fabejárást. 


A visszafelé haladó bejárókat a szabványos reverse iterator sablonok (§19.2.5) segítségével 
határozhatjuk meg. 


17.4.1.2. Bejárók és párok 


A map a szokásos függvényeket biztosítja a bejárók eléréséhez (416.3.29: 


template class Key, class T; class Cmp - lesszKey?, 
class A - allocators paircconst Key, T- : : class map ( 
bublic: 
Ve 
// bejárók 


iterator beginO; 
const iterator beginŐ const; 


iterator endO; 
const iterator endŐ const; 


reverse iterator rbeginŐ); 
const reverse iterator rbeginŐ const; 


reverse iterator rendŐ; 
const reverse iterator rendŐ const; 


Ms 


A map bejárásakor paircconst Key, mapped type: típusú elemek sorozatán haladunk vé- 
gig. Például egy telefonkönyv bejegyzéseit az alábbi eljárással írathatjuk ki: 


void (mapsstring, number:k phone book) 
( 
typedef mapsstring number?:::const iterator CI; 
for (CIp - phone book.beginO; p/!-bhone book.endO; 44p) 
cout ££ p-ofirst cz M! 2£ p-ssecond cz Mi 
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A map bejárói az elemeket kulcs szerint növekvő sorrendben adják vissza (417.1.4.5), így 
a phone book bejegyzései ábécésorrendben jelennek meg. Egy pair első elemére a first, má- 
sodik elemére a second névvel hivatkozhatunk, függetlenül attól, hogy éppen milyen típu- 


súak ezek az elemek: 


template cclass T1, class T22 struct std::bair f( 


typedef T1 first type; 
typedef T2 second type; 


T1 first; 
T2 second; 


bairO :first( TO), second(120) ( ; 
baircconst Ti x, const T2£ y) :first(x), secondO)) ( ) 
templatexciass U, class V: 
bair(const pairsU, V2£ p) :first(b firsb9), second(p.second) ( ) 


); 


Az utolsó konstruktorra azért van szükség, hogy a párokon típuskonverziót is végezhessünk 


(§13.6.29: 


bairsint double: (char c, int i) 


t 

baircchar,int: x(c,i); 

1 s 

return Xx; // pairSchar,int:-ről paircint, double:-ra való konverzió szükséges 
.. return pairsint, doublex(c,i); // konverzió szükséges 
j 


A map esetében a pár első tagja a kulcs, a második tagja a hozzárendelt érték. 


A pair adatszerkezet nem csak a map megvalósításában használható, így ez is egy önálló 
osztály a standard könyvtárban. A pair leírását a Cutility: fejállományban találhatjuk meg. 
A pair típusú változók létrehozását könnyíti meg a következő függvény: 


template cclass T1, class T22 pairsT1, T22 std::make pair(T1 t1, T2 12) 
t 

return pairST1, T22(11,t29; 
J 


A pair alapértelmezett kezdőértékeit két elemtípusának alapértelmezett értéke adja. Fontos, 


hogy ha az elemek típusa beépített, akkor a kezdőérték 0 (45.1.19, karakterláncok esetében 
pedig egy ,üres" karakterlánc (420.3.4). Olyan típus, melynek nincs alapértelmezett 


konstruktora, csak akkor lehet egy pair eleme, ha a pair kezdőértékét kifejezetten megadjuk. 
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17.4.1.3. Indexelés 


A legjellemzőbb map-művelet a hozzárendeléses (asszociációs) keresés, amit az indexelő 
operátor valósít meg: 


template cclass Key, class T; class Cmp - lesszKey:, 
class A - allocator£ paircconst Key, T2 22 

class map f 
bublic: 

440 

mapped typek operatorl const key typeg kJ; / a k kulcsú elem elérése 

18 
2; 
Az indexelő operátor a megadott kulcsot indexnek tekintve egy keresést hajt végre és 
visszaadja a kulcshoz rendelt értéket. Ha a kulcs nem található meg a tárolóban, akkor ez- 
Zel a kulccsal és a mapped type alapértelmezett értékével egy új elem kerül az asszociatív 


tömbbe: 


void JO 
( 
mapsstring, int m; // a map kezdetben üres 
int x - m//Henry I; // új bejegyzés készítése ( Henry"); a kezdőérték O, a 
// visszaadott érték O 
m("Harry] - 7; // új bejegyzés készítése ("Harry"), a kezdőérték O, kapott érték 7 
int y - m/"Henry I; // a "Henry" bejegyzés értékének visszaadása 
m[("Harry"] - 9; // "Harry" értékének módosítása 9-re 


j 


Egy kicsit valóságszerűbb példa: képzeljünk el egy programot, amely kiszámítja a bemene- 
tén megadott tárgyak darabszámát. A listában (név, mennyiség) bejegyzések szerepelnek. 
Az összesítést el szeretnénk végezni tárgyanként és az egész listára is. A lista lehet például 
a következő: 


szög 100 kalapács 2 fűrész 3 fűrész 4 kalapács 7 szög 1000 szög 250 


A feladat nagy részét elvégezhetjük, miközben a (név, mennyiség) párokat beolvassuk egy 
map tárolóba: 


void readitems(mapsstring, int:k£k m) 
( 
string word; 
int val — O; 
while (cin 32 word 52 va  mflwordj 4— val; 


j 
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Az mf/wordj) indexelés azonosítja a megfelelő (string, int) párt, és visszaadja az int értéket. 
A fenti programrészletben kihasználjuk azt is, hogy az új elemek int értéke alapértelmezés 
szerint 0. 


A readitemsO függvénnyel felépített map egy szokásos ciklus segítségével jeleníthető meg: 


int mainŐ 


( 
mapsstring, int: tbl; 
readitems(tbD; 


int total — O; 
typedef mapsstring, int:::const iterator CI; 


Jor (CI p — tbl.beginO; p/-tbl.endO); 43p) ( 
total 4- p-3second; 
cout ££ p-ofirst cz M! ££ p-ssecond cz M; 


) 


cout cz "rre Wösszesen" cz total cz Mn; 


return !cin; 


J 


A fenti bemenettel a függvény eredménye a következő: 


fűrész 7 
kalapács 9 
szög 1350 


összesen 1366 


Figyeljük meg, hogy a nevek ábécésorrendben jelennek meg (417.4.1, §17.4.1.59. 


Az indexelő operátornak meg kell találnia a megadott kulcsértéket a tárolóban. Ez természe- 
tesen nem olyan egyszerű művelet, mint a tömbök esetében az egész értékkel való indexe- 
lés. A pontos költség: O(logra map mérete)). Ez sok alkalmazás esetében még elfogadható, 
ha azonban a mi céljainknak túl drága, érdemesebb hasító tárolót (417.6) használnunk. Ha 
a map tárolóban nem található meg egy kulcs, akkor az erre vonatkozó indexeléssel létre- 
hozunk egy alapértelmezett elemet. Ennek következtében a const map osztályok esetében 
nem használhatjuk az oberatorf/ JO műveletet. Ráadásul az indexelés csak akkor használha- 
tó, ha a mapped type típusnak van alapértelmezett értéke. Ha csak arra vagyunk kíváncsi- 
ak, hogy egy adott kulcs megtalálható-e a tárolóban, akkor használjuk a findO műveletet 
(§17.4.1.609), ami a map megváltoztatása nélkül keresi meg a kulcsot. 
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17.4.1.4. Konstruktorok 


A map a szokásos konstruktorokat és egyéb függvényeket biztosítja (416.3.49: 


template Cclass Key, class T; class Cmp -lesszKey:, 
class A -allocatorgpaircconst Key, 2 2 2 
class map f 
bublic: 
Ms 


// létrehozássmásolás/megsemmisítés: 


explicit map(const Cmpk - CmpO, const A£ - 409; 
template cclass In: mapdin first, In last, const Cmpk - CmpO, const Ak —- 409; 
map(const mapé ); 


-mapO; 
mapk operator-(const mapé ); 


Ms 


A tároló lemásolása azt jelenti, hogy helyet foglalunk az elemeknek, majd mindegyikről má- 
solatot készítünk (416.3.4). Ez nagyon költséges művelet is lehet, ezért csak akkor használ- 
juk, ha elkerülhetetlen. Ebből következik, hogy az olyan tárolókat, mint a map, csak 
referencia szerint érdemes átadni. 


A sablon konstruktor baircconst Key, T- elemek sorozatát kapja paraméterként, amelyet 
egy bemeneti bejáró-párral adunk meg. A függvény a sorozat elemeit az insert0 művelet 
segítségével szúrja be az asszociatív tömbbe. 


17.4.1.5. Összehasonlítások 


Ahhoz, hogy egy adott kulcsú elemet megtaláljunk egy map-ben, a map műveleteinek 
össze kell tudnia hasonlítani a kulcsokat. A bejárók is a kulcsok növekvő értékei szerint ha- 
ladnak végig a tárolón, így a beszúrások is kulcs-összehasonlításokat végeznek (ahhoz, 
hogy az elemeket elhelyezzék a map tárolót ábrázoló faszerkezetben). 


Alapértelmezés szerint a kulcsok összehasonlításához használt művelet a c (kisebb minb 
operátor, de egy sablon- vagy konstruktor-paraméterben más függvényt is megadhatunk 
(§17.3.3). Az itt megadott rendezési szempont a kulcsokat hasonlítja össze, míg a map ese- 
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tében a value type (kulcs, érték) párokat jelent. Ezért van szükség a value compO függ- 
vényre, amely a kulcsokat összehasonlító eljárás alapján a párokat hasonlítja össze: 


template Sclass Key, class T; class Cmp - lesszZKey?:, 
class A - allocators paircconst Key, T: 5 5 
class map ( 
public: 
ÜZ sz 


typedef Cmp key compare; 


class value compare : public binary functionzvalue type,value type,bool: f 
friend class map; 
brotected: 

Cmp cmp; 

value compare(Cmp c) : cmpCC) (1? 
bublic: 

bool operatorO(const value type$k x, const value tybek y) const 

€ return cmp(x first, y.firsD; ) 

J; 


key compare key compO const; 
value compare value compO const; 
Ú sas 
7 
Például: 


mapsstring, int: mI; 


mapsstring, int, Nocasez m2; // összehasonlítás típusának megadása (§17.1.4.1 

mapsstring, int String cmp: m3; // összehasonlítás típusának megadása (§17.1.4.1) 

mapsstring, int, String cmp: má(String cmp(literary));  /7 összehasonlítandó objektum 
// átadása 


A key compO és a value compO tagfüggvény lehetővé teszi, hogy az asszociatív tömbben 
az egész elemekre a csak kulcsokra, illetve a csak értékekre vonatkozó összehasonlító mű- 
veleteket használjuk. Erre legtöbbször akkor van szükség, ha ugyanazt az összehasonlítást 
szeretnénk használni egy másik tárolóban vagy algoritmusban is: 


void Kmapsstring,int:k m) 


( 
mapsstring,int- mm; // összehasonlítás alapértelmezés szerint £ operátorral 
mapsstring, int: mmm(m.key compO); // m szerinti összehasonlítás 
1 za 


J 
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A §17.1.4.1 pontban példát láthatunk arra, hogyan adhatunk meg egyedi összehasonlításo- 
kat, a §18.4 pontban pedig a függvényobjektumok általános bemutatásával foglalkozunk. 


17.4.1.6. Műveletek asszociatív tömbökkel 


A map és természetesen az összes asszociatív tároló legfontosabb tulajdonsága, hogy egy 
kulcs alapján férhetünk hozzá az információkhoz. Ezen cél megvalósításához számos egye- 
di függvény áll rendelkezésünkre: 


template class Key, class T; class Cmp - lesszKey?, 
class A - allocator£ paircconst Key, T2 22 
class map f 
bublic: 
J1aba 


// map-műveletek 


iterator find(const key typeg k); // a k kulcsú elem megkeresése 
const iterator find(const key typek R) const; 


size type count(const key typek k) const; // a k kulcsú elemek számának 
// meghatározása 


iterator lower. bound(const key typeg kJ); // az első k kulcsú elem megkeresése 

const iterator lower. bound(const key typek k) const; 

iterator upper. bound(const Rey typeg k); // az első k-nál nagyobb kulcsú elem 
// megkeresése 

const iterator ubpber. bound(const key typeg R) const; 


bairsiterator iterator: egual range(const key typeg kJ; 
baircconst iterator,const iterator: egual range(const key typeg k) const; 


Me 


Az m find(k) művelet egyszerűen visszaad egy k kulcsú elemre hivatkozó bejárót. Ha ilyen 
elem nincs, akkor a visszaadott bejáró az m.endO. Egy egyedi kulcsokkal rendelkező táro- 
ló esetében (mint a map és a se) az eredmény az egyetlen k kulcsú elemre mutató bejáró 
lesz. Ha a tároló nem teszi kötelezővé egyedi kulcsok használatát (mint a multimap és 
a multisebD, akkor a visszaadott bejáró az első megfelelő kulcsú elem lesz: 


void (mapsstring, int:k m) 


( 


mapsstring,int2::iterator p - m findC "Arany"; 
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if (p-m.endO) f // ha "Arany"-at találtunk 
HAVON 

; 

else if (m findCEzüst")!-m.endO) f // "Ezüst" keresése 
VT 

) 

eb 

J 


Egy multimap (417.4.2) esetében az első k kulcsú elem megkeresése helyett általában az 
összes ilyen elemre szükségünk van. Az m.lower. bound(k) és az m.upper. bound(R) függ- 
vényekkel az m k kulcsú elemeiből álló részsorozat elejét, illetve végét kérdezhetjük le. 
Szokás szerint, a sorozat végét jelző bejáró az utolsó utáni elemre mutat: 


void Kmultimapsstring, int:£ m) 


( 


multimapsstring, int:::iterator lb - m.lower. boundC"Arany"); 
multimapsstring, int2::iterator ub - m.upper. bound("Arany"); 


for (multimapsstring, int2::iterator p -— lb; p!-ub,; 3-4p) ( 
4/5078 
; 
J 


Az alsó és a felső határ meghatározása két külön művelettel nem túl elegáns és nem is ha- 
tékony. Ezért áll rendelkezésünkre az egual range0 függvény, amely mindkét értéket 


visszaadja: 


void Kmultimapsstring, int:£ m) 


( 
typedef multimapsstring, int:::iterator MI; 
bairsMIMI- g - m.egual range("Arany"); 


for (MI p - g first; p!-g.second; 14p) ( 
Vá 


) 
J 


Ha a lower. bound(k) nem találja meg a k kulcsot, akkor az első olyan elemre hivatkozó 
bejárót adja vissza, melynek kulcsa nagyobb, mint g, illetve az endŐ bejárót, ha nem léte- 
zik k-nál nagyobb kulcs. Ugyanezt a hibajelzési módot használja az upber. boundO és az 
egual rangeg is. 
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17.4.1.7. Listaműveletek 


Ha egy asszociatív tömbbe új értéket szeretnénk bevinni, akkor a hagyományos megoldás 
az, hogy egyszerű indexeléssel értéket adunk az adott kulcsú elemnek: 


bhone bookl["Rendelési osztály"] - 8226339; 


Ez a sor biztosítja, hogy a bhone book tárolóban meglesz a Rendelési osztály bejegyzés 
a megfelelő értékkel, függetlenül attól, hogy korábban létezett-e már ilyen kulcs. Elemeket 
beilleszthetünk közvetlenül az insertŐ függvény segítségével is, és az erase0O szolgál az ele- 
mek törlésére: 


template cclass Key, class T, class Cmp - lesszKey?:, 
class A - allocator£ paircconst Key, IT 22 


class map f 
bublic: 
Jets 
// listaműveletek 
bairziterator, bool: insert(const value typek val; // (kulcs, érték) pár beszúrása 
iterator insert(iterator pos, const value type$k val; // a pos csak javaslat 
template Sclass In: void insert(n first, In lasb; /7/ elemek beszúrása sorozatból 
void erase(iterator Dos); // a mutatott elem törlése 
size type erase(const key typeg k); / a k kulcsú elem törlése (ha van ilyen) 
void erase(iterator first, iterator las; // tartomány törlése 
void clearO; // minden elem törlése 
VANYS 


3; 
Az m.insert(val) függvény beszúrja a val értéket, amely egy (Key, 1 párt ad meg. Mivel 
a map egyedi kulcsokkal foglalkozik, a beszúrásra csak akkor kerül sor, ha az m tárolóban 
még nincs ilyen kulccsal rendelkező elem. Az m.insert(r(vaD visszatérési értéke egy 
bairziterator, bool:. A pár második, logikai tagja akkor igaz, ha a val érték ténylegesen be- 
került a tárolóba. A bejáró az m azon elemét jelöli ki, melynek kulcsa megegyezik a val kul- 
csával (val.firsD: 


void (mapsstring, int:k m) 
( 
bairsstring, int: p99(C"Pali", 999; 


bairszmapsstring,int:::iterator, bool: pb - m.insert(p999; 
if (b.second) f 
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// "Pali"-t beszúűrtuk 


, 
else ( 
// "Pali" már szerepelt 
, 
mapsstring,int2::iterator i — p.first;  // points to m("Pali"] 
Ma 


J 
Általában nem érdekel minket, hogy a kulcs korábban már szerepelt-e a map-ben vagy új 
elemként került be. Ha mégis erre vagyunk kíváncsiak, annak oka általában az, hogy a kí- 
vánt kulcs egy másik map tárolóba is kerülhet az általunk vizsgált helyett, és ezt észre kell 
vennünk. Az insertŐ másik két változata nem jelzi, hogy az új érték tényleg bekerült-e 
a tárolóba. 


Ha az insert(bos,val) forma szerint egy pozíciót is megadunk, akkor csak egy ajánlást 
adunk, hogy a rendszer a val kulcsának keresését a bos pozíciótól kezdje. Ha az ajánlás he- 
lyes, jelentős teljesítménynövekedést érhetünk el. Ha nem tudunk jó ajánlást adni, használ- 


juk inkább az előző változatot, mind az olvashatóság, mind a hatékonyság érdekében: 


void Kmapsstring int:k m) 


( 
ml" DilbertJ] - 3; // elegáns, de valószínűleg kevésbé hatékony 
m.insert(m.beginO, make pair(const string( "Dogbert"), 99); // csúnya 

J 


Valójában a / / egy kicsit több, mint egyszerűen az insertO0 kényelmesebb alakja. Az m[k/ 
eredménye a következő kifejezéssel egyenértékű: 


Ct(m.insertr(make pair(k, VO)) firs0).second 


ahol a VO a hozzárendelt érték alapértelmezett értékét jelöli. Ha ezt az egyenértékűséget 
megértettük, akkor valószínűleg már értjük az asszociatív tárolókat is. Mivel a / /mindenkép- 
pen használja a VŐ értéket, nem használhatjuk az indexelést olyan map esetében, melynek 
értéktípusa nem rendelkezik alapértelmezett értékkel. Ez egy sajnálatos hiányossága az 
asszociatív tárolóknak, annak ellenére, hogy az alapértelmezett érték megléte nem alapvető 
követelményük (d. §17.6.2). Az elemek törlését is kulcs szerint végezhetjük el: 


void Kmapsstring,int:k m) 


( 


int count - m.erase("Ratbert"); 
V/G 
J 
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A visszaadott egész érték a törölt elemek számát adja meg. Tehát a count tartalma 0, ha 
nincs , Ratbert" kulcsú elem a tárolóban. A multimap és a multiset esetében a visszaadott 
érték egynél nagyobb is lehet. Egy elemet egy rá mutató bejáró segítségével törölhetünk, 
elemek sorozatát pedig a megfelelő tartomány kijelölésével: 


void g((mapsstring,int:£ m) 


( 
m.erase(rm find("Catbert")); 


m.erase(rm findC Alice"), m findC"Wally"; 
2 


2 
Természetesen gyorsabban lehet törölni egy olyan elemet, melynek már megtaláltuk 
a bejáróját, mint egy olyat, melyet először a kulcs alapján meg kell keresnünk. Az eraseO 
után a bejárót tovább már nem használhatjuk, mivel az általa mutatott elem megsemmisült. 
Az m.erase(b,e) hívása, ahol e értéke m.endO veszélytelen (b vagy m valamelyik elemére 
hivatkozik, vagy m.endO). Ugyanakkor az m.erase(p) meghívása, amennyiben b értéke 
m.endO, súlyos hiba és tönkreteheti a tárolót. 


17.4.1.8. További műveletek 


A map biztosítja azokat a szokásos függvényeket, melyek az elemek számával foglalkoz- 
nak, illetve egy specializált swapO függvényt: 


template cclass Key, class T, class Cmp - lesszKey?:, 
class A - allocator£ paircconst Key, T2 22 
class map f 
bublic: 
Aaa 
// kapacitás: 


size type sizeO const; // elemek száma 
size type max sizeO const; // a lehetséges legnagyobb map mérete 
bool emptyO const f return size0—-0; ) 


void swap(mapk ); 
2. 


Jo 
Szokás szerint a size és a max sizeO által visszaadott érték valamilyen elemszám. 


Ezenkívül a map használatakor rendelkezésünkre állnak az összehasonlító operátorok (-—, 
1-, c, 5, cz, 57), valamint a swapO eljárás is, ezek azonban nem tagfüggvényei a map 
osztálynak: 
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template cclass Key, class T, class Cmp, class A: 
bool operator-—(const mapcKey, T, Cmp, Azk, const mapcKey, T, Cmp, A2£ ); 








// ugyanígy !-, £, 2, cz, and 2 


template cclass Key, class T, class Cmp, class Az 
void swap(mapcKey, T,Cmp, Azk, mapsKey, T,Cmp, A2£ J; 


Miért lehet szükség arra, hogy két asszociatív tömböt összehasonlítsunk? Ha két map objek- 
tumot hasonlítunk össze, általában nem csak azt akarjuk megtudni, hogy egyenlőek-e, ha- 
nem azt is, hogy miben különböznek, ha különböznek. Ilyenkor tehát az —— és a /- nem 
használható. Az -——, a £ és a swapO megvalósításával azonban lehetővé válik, hogy olyan 
algoritmusokat készítsünk, melyek minden tárolóra alkalmazhatók. Ezekre a függvényekre 
például akkor lehet szükségünk, ha asszociatív tömbökből álló vektort szeretnénk rendez- 
ni vagy map tárolók halmazára van szükségünk. 


17.4.2. A multimap 


A multimap nagyon hasonlít a map tárolóra, azzal a kivétellel, hogy ugyanaz a kulcs több- 
ször is szerepelhet: 


template cclass Key, class T, class Cmp - lesszZKey?:, 
class A — allocators paircconst Key, T: 5 2 
class std::multimap f 
bublic: 
// mint a map, kivéve a következőt: 


iterator insert(const value typek); — // bejárót ad vissza, nem párt 


// nincs indexelő operátor (( )) 
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Például (felhasználva a §17.1.4.1 pontban C stílusú karakterláncok összehasonlításához be- 
mutatott CString less osztályD: 


void Kmapcchar" int, Cstring lesszgk m, multimapcchar", int, Cstring lesszk mm) 
f 

m.insert(rmake pairCx" 4); 

m.insert(rmake pair(x",5)9;// nincs hatása: "x" már szerepel (§17.4.1.7) 

// most m[/x"] -— 
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mm .insert(rmake pairC(x" 4); 
mm.insert(make pairCx",5)); 
// mm most ("x",4)-et és (1x",5)-öt is tartalmazza 


J 


Tehát a multimap tárolóban nem lehet olyan indexelést megvalósítani, mint a map eseté- 
ben. Itt az egual rangeO, a lower. boundO és az upper boundO művelet (§17.4.1.6) jelen- 
ti az azonos kulcsú elemek elérésére szolgáló legfőbb eszközt. 


Természetesen ha ugyanahhoz a kulcshoz több értéket is hozzárendelhetünk, akkor a map 
helyett feltétlenül a multimap szerkezetet használjuk. Ez pedig sokkal gyakrabban előfor- 
dul, mint gondolnánk. Bizonyos tekintetben a multimap sokkal tisztább és elegánsabb 
megoldást ad, mint a map. 


Mivel egy embernek több telefonszáma is lehet, a telefonkönyvet is érdemesebb multimap 
formában elkészíteni. Saját teletonszámaimat például a következő programrészlettel jelenít- 
hetem meg: 


void print numbers(const multimapcstring, int:k phone book) 


( 

typedef multimapsstring,int:::const iterator I; 

bairsI,I- b - phone book.egual rangeC"Stroustrup"); 

for d i - b first; i !- b.second; 441) cout ££ i-3second CZ Mi; 
2 


J 

A multimap esetében az insertŐ mindig beilleszti a paramétereként megadott elemet, így 
nincs szükség a pairxiterator, bool: típusú visszatérési értékre; a multimap::insertŐ egyet- 
len bejárót ad vissza. Az egységesség érdekében a könyvtár tartalmazhatná az insertO álta- 
lános formáját, mind a map-hez, mind a multimap-hez, annak ellenére, hogy a bool rész fe- 
lesleges a multimap osztályban. Egy másik tervezési szemlélet szerint elkészíthették volna 
az egyszerű insertO függvényt mindkét tárolóhoz, amely nem ad vissza logikai értéket. Ez 
esetben viszont a map felhasználóinak valamilyen más lehetőséget kellett volna biztosítani 
annak megállapításához, hogy új kulcs került-e a tárolóba. Ebben a kérdésben a különbö- 
ző felülettervezési elméletek ütköztek, és nem született megegyezés. 


17.4.3. A set 


A set (halmaz) olyan egyedi map (§17.4.1) tárolónak tekinthető, ahol a hozzárendelt érté- 
kek érdektelenek, így csak a kulcsokat tartjuk meg. Ez a felületnek csupán apró módosítá- 
sát jelenti: 
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template cclass Key, class Cmp - lesszKey:, class A - allocatorcKey: : 
class std::set f 
bublic: 

// mint a map, kivéve a következőt 


typedef Key value type; // a kulcs maga az érték 
typedef Cmp value compare; 
// nincs indexelő operátor (( )) 


bő 


A value type típust tehát itt a key type típussal azonosként határozzuk meg. Ez a trükk le- 
hetővé teszi, hogy nagyon sok esetben ugyanazzal a programmal kezeljünk egy map és egy 
set tárolót. 


Figyeljük meg, hogy a set egy sorrendvizsgáló operátort használ (alapértelmezés szerint 2), 
és nem egyenlőséget (-5) ellenőriz. Ennek következtében az elemek egyenértékűségét 
a nem-egyenlőség határozza meg (417.1.4.1) és a halmaz bejárásakor az elemeket megha- 
tározott sorrendben kapjuk meg. 


Ugyanúgy, mint a map esetében, itt is rendelkezésünkre állnak a halmazokat összehason- 
lító operátorok (-—, /- c , 5, C-, 55) és a swapO függvény is. 


17.4.4. A multiset 


A multiset egy olyan halmaz, amely megengedi, hogy ugyanazok a kulcsok többször is elő- 
forduljanak: 


template cclass Key, class Cmp - lessZKey:, class A - allocatorcKey: : 
class std::multiset f 
bublic: 
// mint a set, kivéve a következőt: 
iterator insert(const value typed ); // bejárót ad vissza, nem párt 


3 


A többször előforduló kulcsok eléréséhez elsősorban az egual rangeO, a lower. boundO 
és az upper. boundO függvényeket használhatjuk. 
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17.5. Majdnem-tárolók 


A beépített tömbök (45.29, a karakterláncok (20. fejezed, valamint a valarray (422.4) és 
a bitset (§17.5.3) osztályok is elemeket tárolnak, így sok szempontból tárolónak tekinthet- 
jük őket. Mindegyik hordoz azonban néhány olyan vonást, amely ellentmond a szabványos 
tárolók elveinek, ezért ezek a ,majdnem-tárolók" nem mindig cserélhetők fel a teljesen ki- 
fejlesztett tárolókkal, például a vector vagy a list osztályokkal. 


17.5.1. Karakterláncok 


A basic string osztály lehetőséget ad indexelésre, használhatunk közvetlen elérésű bejáró- 
kat és a tárolóknál megszokott kényelmi lehetőségek többsége is rendelkezésünkre áll (20. 
fejeze)0. A basic string azonban nem teszi lehetővé, hogy annyiféle típust használjunk 
elemként, mint a tárolókban. Leginkább karakterláncokhoz felel meg és általában a tárolók- 
tól jelentősen eltérő formában használjuk. 


17.5.2. A valarray 


A valarray kifejezetten a számokkal végzett műveletekhez készült vektor, így nem is akar 
általános tároló lenni. Ehelyett számos hasznos matematikai műveletet biztosít, míg a szab- 
ványos tárolók műveletei (417.1.1) közül csak a size és az indexelés áll a rendelkezésünk- 
re (422.4.2). A valarray elemeit közvetlen elérésű bejáróval érhetjük el (419.2.1. 


17.5.3. Bithalmazok 


Egy rendszer szempontjából gyakran van szükség arra, hogy például egy bemeneti adatfo- 
lyamot (421.3.3) egy sor kétértékű (például jó/rossz, igaz/hamis, kikapcsolt/bekapcsolt) ál- 
lapotjelzővel írjunk le. A C4- egész értékekre megvalósított bitszintű műveletek segítségé- 
vel támogatja az ilyen állapotjelzők hatékony kezelését (amennyiben csak néhány van 
belőlük). Ilyen művelet az £ (és), a I (vagy), a A (kizáró vagy), a cc (léptetés balra) és a 32 
Cdéptetés jobbra). A bitsetkN: osztály ezt a fogalmat általánosítja. Segítségével egyszerűen 
végezhetünk műveleteket N darab biten, melyeket 0-tól M- 71-ig indexelünk. Az N értékét 
fordítási időben rögzítjük. Egy olyan bitsorozat esetében, amely nem fér el egy long int vál- 
tozóban, a bitset használata sokkal kényelmesebb, mint az int értékek közvetlen kezelése. 
Kevesebb jelzőbit esetében hatékonysági szempontok alapján kell döntenünk. Ha a biteket 
sorszámozás helyett el szeretnénk nevezni, halmazt (set, §17.4.3), felsorolási típust (44.8), 
vagy bitmezőt (bitfield, $C.8.1) használhatunk. 
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A bitsetZN: N darab bit tömbjének tekinthető. A bitset a vectorcbool: osztálytól abban kü- 
lönbözik, hogy rögzített méretű, a set tárolótól abban, hogy egészekkel és nem asszociatív 
értékkel indexelhető, illetve mindkettőtől eltér abban, hogy közvetlen bitműveleteket kínál. 


Egy beépített mutató (45.1) segítségével nem tudunk biteket kijelölni, ezért a bitset osztály- 
nak meg kell határoznia egy , hivatkozás bitre" típust. Ez a módszer általánosan használha- 
tó olyan objektumok esetében, melyekhez a beépített mutatók valamilyen okból nem 
használhatók: 


templatecsize t N: class std::bitset f 


bublic: 
class reference ( // hivatkozás egyetlen bitre 
friend class bitset; 
referenceO; 
public: // b[i) az Ci: 19-edik bitre hivatkozik 
-referenceO; 
referencekg operator-(bool x); // blij — x; 
referencek operator—(const referenced );  blij — Díjl; 
bool operator-) const; / return -b[íj 
operator boolO const; 47 x — blil: 
referenceg flipO; // blij fipO; 
3; 
VAS 
zs 


A bitset sablon az szd névtérhez tartozik és a cbitset: fejállomány segítségével érhetjük el. 


A C44 történetére visszanyúló okokból a bitset néhány szempontból eltér a standard könyv- 
tár osztályainak stílusától. Például, ha egy index (amit gyakran bitbozíciónak nevezünk) kí- 
vül esik a megengedett tartományon, akkor egy out of range kivétel keletkezik. Nem áll- 
nak rendelkezésünkre bejárók. A bitpozíciókat jobbról balra számozzuk, ugyanúgy, ahogy 
a biteket egy gépi szóban. Így a blíi/ bit értéke pow(2,i. A bitset tehát egy N bites bináris 
számnak tekinthető: 


pozició 9 g8 7 6 5 4 3 2 1 0 
bitsetc105(989) J1l11]1 TEA ES ÉS ÉSÉRE 
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17.5.3.1. Konstruktorok 


Egy bitset objektumot létrehozhatunk alapértelmezett értékkel, valamint egy unsigned long 
int vagy egy string bitjeiből is: 


templatecssize t N: class bitset f 


bublic: 

FZÁEY 

// konstruktorok 

bitsetO; //N nulla bit 

bitset(unsigned long vaD; // bitek a val-ból 

templatexclass Ch, class Tr, class Az // Tr karakter-jellemző (§20.2) 

explicit bitset(const basic stringZCh, Ir, A2€ str, // bitek az str karakterláncból 
basic stringZCh, Tr, A2::size type pos — O, 
basic stringZCh, Tr, A2::size type n -— basic stringZCh, Tr, A2::npos); 

VAY 


J; 


A bitek alapértelmezett értéke 0. Ha unsigned long int paramétert adunk meg, akkor 
a szám minden egyes bitje a neki megfelelő bit kezdőértékét határozza meg. A basic string 
(20. fejeze) ugyanígy működik; a 0" karakter jelenti a 0 bitértéket, az "7" karakter az 7 bit- 
értéket. Minden más karakter invalid argument kivételt vált ki. Alapértelmezés szerint 
a rendszer a bitek beállításához teljes karakterláncot használ, de a basic string 
konstruktorának (420.3.4) megfelelő stílusban megadhatjuk, hogy a karaktereknek csak egy 


résztartományát használjuk, a bos pozíciótól kezdve a lánc végéig vagy a bostn pozícióig: 


void JO 
t 
bitsetS102 b1; //all o 
bitsetS162 b2 - O0xaaaa; // 1010101010101010 
bitsetc325 b3 - Oxaaaa; // 0999090900000000001010101010101010 
bitsetSK102 b4á("1010101010"); // 1010101010 
bitsetS102 b5("10110111011110",49; // 0111011110 
bitsetSK105 b6("10110111011110",2,99; // 0011011101 
bitsetS102 b7("n0g00d"); // invalid argument váltódott ki 
bitsetS10: b8 - "n0Og00d"; // hiba: nincs char?-ról bitset-re való átalakítás 


j 


A bitset osztály alapvető célja az, hogy egyetlen gépi szó helyigényű bitsorozathoz haté- 
kony megoldást adhassunk. A felületet ennek a szemléletnek megfelelően alakították ki. 
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17.5.3.2. Bitkezelő műveletek 


A bitset számos olyan műveletet biztosít, melyekkel egyes biteket érhetünk el vagy az 
összes bitet egyszerre kezelhetjük: 


templatecsize t N: class std::bitset f 


public: 

HI sss 

// bithalmaz-műveletek 

reference operatorl I(size t bos); // blij 

bitsetk operatord-(const bitselgt 5); // és 

bitsetk operator 1—(const bitsetgt 5); // vagy 

bitsetk operatorN—(const bitsetgt 5); // kizáró vagy 

bitsetk oberatorcc—(size tn); // logikai eltolás balra (feltöltés nullákkal) 

bitsetk: oberator:5—(Ssize tn); // logikai eltolás jobbra (feltöltés nullákkaD 

bitsetk setO; // minden bit 1-re állítása 

bitsetk set(size t pos, int val - 1; // bíposJ-val 

bitsetk resetO; // minden bit 0-ra állítása 

bitsetk reset(size t pos); // bíposJ-o 

bitseik flipO; // minden bit értékének módosítása 

bitsetk flip(size t bos); // bípos] értékének módosítása 

bitset operator-0 const ( return bitsetZkN:2("this) flipO; )  // komplemens halmaz 
// létrehozása 

bitset operatorsásize t n) const f return bitsetZN2x(tthis)cczn,; ) // eltolt halmaz 

// létrehozása 
bitset operator2(size t n) const f return bitsetZN2(tthis)2P-n,; ) // eltolt halmaz 
// létrehozása 


ze 
Vö 


Az indexelő operátor out of range kivételt vált ki, ha a megadott index kívül esik a meg- 
engedett tartományon. Nem ellenőrzött indexelésre nincs lehetőség. 


A műveletek által visszaadott bizsetk érték a "this. Azok a műveletek, melyek a bitsetik he- 
lyett bitset értéket adnak vissza, egy másolatot készítenek a "zhis objektumról, ezen a má- 
solaton végzik el a kívánt műveletet, és ennek eredményét adják vissza. Fontos, hogy a cc 
és a 535 műveletek itt tényleg eltolást jelentenek és nem be- vagy kimeneti műveleteket. 
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A bitset kimeneti operátora egy olyan CZ függvény, melynek két paramétere egy ostream 
és egy bitset (§17.5.3.3). 


Amikor a biteket eltoljuk, logikai eltolás történik (tehát nem ciklikus). Ez azt jelenti, hogy 
néhány bit , kiesik", mások pedig az alapértelmezett O értéket kapják meg. Mivel a size ttí- 
pus előjel nélküli, arra nincs lehetőségünk, hogy negatív számmal toljuk el a bitsorozatot. 
Ennek következtében a bcc-17 utasítás egy igen nagy pozitív számmal tolja el a biteket, így 
a b bitset minden bitjének értéke 0 lesz. A fordítók általában figyelmeztetnek erre a hibára. 


17.5.3.3. További műveletek 


A bitsetis támogatja az olyan szokásos műveleteket, mint a size(), az ——, a ki- és bemenet stb..: 
templatecssize t N: class bitset f 
bublic: 
Ms 
unsigned long to ulongO const; 


template cclass Ch, class Tr, class Az basic stringZCh, Tr,A? to stringO const; 


size t countO const; // 1 értékű bitek száma 
size t sizeO const f return N; ) // bitek száma 


bool operator-—(const bitsetk s) const; 
bool operator!-(const bitsetk s) const; 


bool test(size t pos) const; // igaz, ha bípos] értéke 1 
bool anyO const; // igaz, ha bármelyik bit értéke 1 
bool noneO const; // igaz, ha egyik bit értéke sem 1 


J; 


A to ulongÓ0 és a to stringO függvény a megfelelő konstruktor fordított (inverz) művelete. 
A félreérthető átalakítások elkerülése érdekében a szokásos konverziós operátorok helyett 
a fenti műveletek állnak rendelkezésünkre. Ha a bitset objektumnak olyan bitjei is értéket 
tartalmaznak, melyek nem ábrázolhatók unsigned long int formában, a to ulongO függ- 


vény overflow error kivételt vált ki. 


A to stringO művelet a megfelelő típusú karakterláncot állítja elő, amely "0" és "7" karakte- 
rekből épül fel. A basic string a karakterláncok ábrázolásához használt sablon (20. fejeze0. 
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A to stringO függvényt használhatjuk egy int bináris alakjának kiíratásához is: 


void binary(int i) 
( 
bitsetzstsizeof(inD: b - i; // 8 bites bájtot tételezünk fel (lásd még §22.2) 
cout c£ b.template to stringZ char,char. traitsZchar:, allocatoráchar: 20 cz Mn; 


J 


Sajnos egy minősített sablon tag meghívása igen bonyolult és ritkán használt utasításformát 


követel (4C.13.6). A tagfüggvényeken kívül a bizset lehetővé teszi a logikai £ (és), a ! (vagy), 
a A (kizáró vagy), valamint a szokásos ki- és bemeneti operátorok használatát is: 


templatecssize t N: bitsetSZN: std::oberatork (const bitsetzN:k, const bitsetzN:£ ); 
templatecssize t N2 bitsetzN: std::operator I(const bitsetZN:k, const bitsetZN2£ ); 
templatecssize t N2 bitsetzZN: std::oberatorMconst bitsetZkN:k, const bitsetZN2£ ); 


template cclass charT; class Tr, size t N- 

basic istreamácharT;Ir:£ std::operator:P(basic istreamácharT;Tr:£, bitsetzN-£ ); 
template cclass charT; class Tr, size t N- 

basic ostreamácharT;Tr:£ std::operatorszz(basic ostreamácharT;Tr:£k, const bitsetzN-£ ); 


Tehát egy bitset objektumot kiírathatunk anélkül is, hogy előbb karakterlánccá alakítanánk: 


void binary(int i) 

( 
bitsetcstsizeof(inD: b -— i; // 8 bites bájtot tételezünk fel (lásd még §22.2 
cout cz b cc Mt 


J 


Ez a programrészlet nullák és egyesek formájában írja ki a biteket és a legnagyobb 
helyiértékű bit lesz a bal oldalon. 


17.5.4. Beépített tömbök 


A beépített tömbök támogatják az indexelést és — a szokásos mutatók formájában — 
a közvetlen elérésű bejárók használatát is (§2.7.29. A tömb azonban nem tudja a saját mére- 
tét, így a programozónak kell azt nyilvántartania. A tömbök általában nem biztosítják 
a szabványos tagműveleteket és -típusokat. 


Néha nagyon hasznos az a lehetőség, hogy egy beépített tömböt elrejthetünk a szabványos 
tárolók kényelmes jelölésrendszere mögé, úgy, hogy közben megtartjuk alacsonyszintű ter- 
mészetének előnyeit: 
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templatecciass T, int max? struct c array f 
typedef T value type; 


typedef T" iterator; 
typedef const T" const iterator; 


typedef Ik reference; 
typedef const Tk const reference; 


T umaxl; 
operator 1" ( return vu; ) 


reference operatorfl (size t i) f return ulij; ) 
const reference operatorl Kptrdijff" t i) const f return ulij; ) 


iterator beginO ( return vu; ) 
const iterator beginO const f return u; ) 


iterator endŐ f return vtmax; ) 
const iterator endŐ const f return vtmax; ) 


pbtrdijff t sizeO const f return max; ) 
2. 


9 E 
A tömbökkel való kompatibilitás miatt az előjeles pirdijff" t típust (16.2.2) használom index- 
ként az előjel nélküli size t helyett. 


A c array sablon nem része a standard könyvtárnak. Mindössze egyszerű példaként szere- 
pel itt arra, hogy egy , idegen" tárolót hogyan igazíthatunk a szabványos tárolók keretrend- 
szeréhez. Ez az osztály olyan szabványos algoritmusokhoz (18. fejezet) használható, me- 
lyeknek a beginO, endO stb. műveletekre van szükségük. A verembe anélkül helyezhető, 
hogy közvetve dinamikus memóriát használnánk, és ezenkívül átadható olyan C stílusú 
függvényeknek is, melyek mutatót várnak paraméterként: 


void Kint" p, int sz); // C stílus 
void gO 
( 
c arrayáint, 102 a; 
Ha,a.sizeO); // C stílusú használat 
c arrayáint, 102::iterator p - find(a.beginO, a.endO, 7779;  CAA/STI stílusú 
// használat 


17 eres 


J 
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17.6. Új tárolók létrehozása 


A szabványos tárolók olyan keretrendszert biztosítanak, melyet a programozó szabadon 
bővíthet. Az alábbiakban azt mutatom be, hogyan készíthetünk olyan tárolókat, melyek fel- 
cserélhetők a szabványos tárolókkal, ha indokolt. A bemutatott példa a gyakorlatban is mű- 
ködik, de nem optimális. A felületet úgy választottam meg, hogy az nagyon közel álljon 
a hash map létező, széles körben elérhető, magas szintű megvalósításaihoz. Az itt bemuta- 
tott hash map arra használható, hogy megtanuljuk az általános alapelveket. Komoly mun- 


kához használjunk inkább a támogatott hash map típust. 


17.6.1. A hash map 


A map olyan asszociatív tároló, melynek szinte bármilyen típusú eleme lehet, hiszen az 
egyetlen követelmény egy ,kisebb mint" művelet az elemek összehasonlításához 
(§17.4.1.59. Ha azonban többet tudunk a kulcs típusáról, általában lerövidíthetjük az elemek 
megtalálásához szükséges időt, azzal, hogy hasító függvényt (hash function) készítünk és 
a tárolót hasító táblaként (hash table) valósítjuk meg. 


A hasító függvény egy olyan eljárás, amely egy értékhez gyorsan hozzá tud rendelni egy in- 
dexet, mégpedig úgy, hogy két különböző érték ritkán kapja ugyanazt. A hasító tábla ez- 
után lényegében úgy működik, hogy az értéket a kiszámított indexre helyezi, ha az még 
üres, ellenkező esetben az index , közelébe". Ha egy elem a hozzá rendelt indexen találha- 
tó, akkor annak megtalálása nagyon gyors lehet, de az index , közelében" elhelyezett elem 
keresése sem túl lassú, ha az elemek egyenlőségének vizsgálata megfelelően gyors. Ezért 
aztán nem ritka, hogy olyan nagyobb tárolók esetében, ahol a keresés a legjelentősebb mű- 
velet, a hash map akár 5—10-szer gyorsabban végzi el ezt a feladatot, mint a map. Ugyan- 
akkor az is igaz, hogy a hash map egy rosszul megválasztott hasító függvénnyel még 
a map-nél is sokkal lassabb lehet. 


Hasító táblát sokféleképpen készíthetünk. A hash table felületének csak ott kell különböz- 
nie a szabványos tárolók felületétől, ahol a hasítás hatékonysága ezt megköveteli. A leg- 
alapvetőbb különbség a map és a hash map között, hogy a map a — művelettel hasonlítja 
össze az elemeit, míg a hash map az -- műveletet használja és szüksége van egy hasító 
függvényre is. Tehát ha a hash map objektumot nem alapértelmezett beállításokkal akar- 
juk létrehozni, akkor a paraméterek jelentősen eltérnek a map tárolónál használtaktól: 


mapsstring, int: mI; // karakterláncok összehasonlítása £ használatával 
mapsstring, int, Nocasez m2; // karakterláncok összehasonlítása NocaseO 
// használatával (§17.1.4. 
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hash mapsstring int: hm1I; // hasítás Hashsstring2Ő0 használatával (§17.6.2.3), 
// összehasonlítás -—- használatával 

hash mapsstring,int,hfct2 hm2; // hasítás hfctO használatával, összehasonlítás -- 
// használatával 

hash mapsstring,int hfct,egl- hm3; — // hasítás hfctO használatával, összehasonlítás egl 
// használatával 


A hasításos keresést használó tárolót egy vagy több táblázat segítségével hozhatjuk létre. 
Az elemek tárolásán kívül a tárolónak nyilván kell tartania azt is, milyen értéket milyen ha- 
sított értékhez (az előzőekben , index") rendelt hozzá. Erre szolgál a , hasító tábla". A hasí- 
tó táblák teljesítménye általában jelentősen romlik, ha túlságosan telítetté válnak, tehát 
mondjuk 75 százalékig megteltek. Ezért az alábbiakban leírt hash map automatikusan nö- 
veli méretét, ha túl telítetté válik. Az átméretezés azonban rendkívül költséges művelet le- 


het, így mindenképpen lehetővé kell tennünk egy kezdeti méret megadását. 


Ezek alapján a hash map első változata a következő lehet: 


templatexciass Key, class T, class H - HashxKey:, 
class EO - egual tozKey?, class A - allocator: paircconst Key, T2 22 
class hash map f 
// mint a map, kivéve a következőket: 


typedef H Hasher; 
typedef EO key. egual; 


hash map(const Tk dv -TO, size type n -101, const H£ hf-HO, const EOk -E009; 
templatexclass In: hash mapdin first, In last, 
const Ik dv -TO, size type n -101, const Hk hf -HO, const EO0£k -E009; 


J; 


Ez lényegében megegyezik a map felületével (417.4.1.4), csak a c műveletet az —— operá- 
torral helyettesítettük és megadtunk egy hasító függvényt is. 


A könyvben eddig használt map objektumok (§3.7.4, §6.1, §17.4.1) könnyedén helyettesíthetők 
a hash map szerkezettel. Nem kell mást tennünk, csak a map nevet át kell írnunk hash map- 


re. A map cseréjét hash map-re általában leegyszerűsíthetjük egy tybpedef utasítással: 


typedef hash mapsstring, record: Map; 
Map dictionary; 


A typedefarra is használható, hogy a szótár (dictionary) tényleges típusát elrejtsük a felhasz- 
nálók elől. 
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Bár a meghatározás nem egészen pontos, a map és a hash map közötti ellentétet tekinthet- 
jük egyszerűen tár-idő ellentétnek. Ha a hatékonyság nem fontos, nem érdemes időt veszte- 
getni a közöttük való választásra: mindkettő jól használható. Nagy és nehézkesen használ- 
ható táblák esetében a hash map jelentős előnye a sebesség, és ezt érdemes használnunk, 
hacsak nem fontos a kis tárigény. Még ha takarékoskodnunk is kell a memóriával, akkor is 
érdemes megvizsgálnunk néhány egyéb lehetőséget a tárigény csökkentésére, mielőtt az 
map szerkezetet választjuk. Az aktuális méret kiszámítása nagyon fontos ahhoz, 
hogy ne egy alapjaiban rossz kódot próbáljunk optimalizálni. 


Legy 


, egyszerű 


A hatékony hasítás megvalósításának legfontosabb része a megfelelő hasító függvény meg- 
választása. Ha nem találunk jó hasító függvényt, akkor a map könnyen túlszárnyalhatja 
a hash map hatékonyságát. A C stílusú karakterláncokra vagy egész számokra épülő hasí- 
tás általában elég hatékony tud lenni, de mindig érdemes arra gondolnunk, hogy egy hasí- 
tó függvény hatékonysága nagymértékben függ az aktuális értékektől, melyeket hasítanunk 
kell (§17.8[(35D. A hash map tárolót kell használnunk akkor, ha a kulcshoz nem adhatunk 
meg c műveletet vagy az nem felel meg elvárásainknak. Megfordítva: a hasító függvény 
nem határoz meg az elemek között olyan sorrendet, mint amilyet a £ operátor, így a map 
osztályra van szükségünk, ha az elemek sorrendje fontos. A map osztályhoz hasonlóan 
a hash mapis biztosít egy findO függvényt, amely megállapítja, hogy egy kulcs szerepel-e 
már a tárolóban. 


17.6.2. Ábrázolás és létrehozás 


A hash map sokféleképpen megvalósítható. Itt egy olyan formát mutatok be, amely vi- 
szonylag gyors, de legfontosabb műveletei elég egyszerűek. Ezek a műveletek 
a konstruktorok, a keresés (a / / operátor), az átméretezés és az egy elem törlését végző 
függvény (eraseO). 


A hasító tábla itt bemutatott egyszerű megvalósítása egy olyan vektort használ, amely a be- 
jegyzésekre hivatkozó mutatókat tárolja. Minden bejegyzésben (Entry) szerepel egy kulcs 
(key), egy érték (value) , egy mutató a következő ugyanilyen hasítókóddal rendelkező 
Entry bejegyzésre (ha van ilyen), illetve egy töröltséget jelző (erased) bit: 








3 kulcs érték törölt következő 











kulcs érték törölt következő 
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Ez deklaráció formájában a következőképpen néz ki. 


templatexciass Key, class T, class H - HashxKey:, 


class EO - egual tozKey?:, class A - allocators paircconst Key, T2 22 
class hash map f 


288 
private: // ábrázolás 
struct Entry f 
key type key; 
mapped type val; 
bool erased; 
Entry?" next; // hash-tűlcsordulás esetére 
Entry(key type k, mapbed type v, Entry? n) 
: key(k), vak(v), next(n), erased(false) ( ) 
5 


vectorsEntry2 vu; // az aktuális bejegyzések 
vectorSEntryt: b; // a hasító tábla: mutató v-be 


Mé 


Vizsgáljuk meg az erased bit szerepét. Az ugyanolyan hasítókóddal rendelkező elemek ke- 
zelésének módja miatt nagyon nehéz lenne egy bizonyos elemet törölni. Ezért a tényleges 
törlés helyett az erase ) meghívásakor csak az erased bitet jelöljük be, és az elemet mind- 
addig figyelmen kívül hagyjuk, amíg a táblát át nem méretezzük. 


A fő adatszerkezet mellett a hash map osztálynak egyéb adatokra is szüksége van. Termé- 
szetesen minden konstruktornak az összes adattagot be kell állítania: 


templatecciass Key, class T, class H - HashxKey:, 


class EO - egual tozKey?2, class A - allocators paircconst Key, T2 52 
class hash map f 


v/dere 


hash map(const Ig dv -TO, size type n -101, const Hg h -HO, const EO£ e -E00) 
: default value(dv), b(n), no of erased(0), hash(h), eg(e) 
í 


set loadO; // alapértelmezés 

v.reserve(rmax loadtb.sizeO); // hely biztosítása a növekedéshez 
) 
void set load(float m - 0.7, float g - 1.6) f max load - m; grow - g; ) 


VST 
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Private: 
float max load; // v.sizeOS-b. size ) "max load megtartása 
float grow; // ha szükséges, resizelr(bucket countO?"grow) 
size type no of erased; // v azon bejegyzéseinek száma, amelyeket törölt elem foglal el 
Hasher hash; // hasító függvény 
key egual eg; // egyenlőség 
const T default value; // a [] által használt alapértelmezett érték 
j; 


A szabványos asszociatív tárolók megkövetelik, hogy a hozzárendelt érték típusa alapértel- 
mezett értékkel rendelkezzen (417.4.1.7). Ez a követelmény valójában nem elengedhetetlen 
és bizonyos esetekben nagyon kényelmetlen is lehet. Ezért az alapértelmezett értéket para- 


méterként vesszük át, ami lehetővé teszi a következő sorok leírását: 


hash mapsstring, Number: phone book1; // alapértelmezés: NumberO 
hash mapsstring, Number: pbhone book2XNumberC411)9; / alapértelmezés: Number(411) 


17.6.2.1. Keresések 


Végül elérkeztünk a kritikus keresési függvényekhez: 


templatecxciass Key, class T, class H - HashxKey-, 


class EO - egual tozKey?:, class A - allocators paircconst Key, IT: 2 5 
class hash map f 


Aza 
mapped typeg operatorl Kconst key typeg ); 


iterator find(const key type£ ); 
const iterator find(const key typek ) const; 
1 gt 


); 


Az értékek megtalálásához az operatorf JO a hasító függvényt használja, mellyel kiszámítja 
a kulcshoz tartozó indexet a hasító táblában. Ezután végignézi az adott index alatt találha- 
tó bejegyzéseket, amíg meg nem találja a kívánt kulcsot. Az így megtalált Entry objektum- 
ban található az a value érték, amelyet kerestünk. Ha nem találtuk meg a kulcsot, akkor 
alapértelmezett értékkel felveszünk egy új elemet: 
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templatexciass Key, class T, class H - HashxKey:, 
class EO - egual tosKey?, class A - allocators paircconst Key, IT: 52 
hash mapcKey, T;H,EO,A2::mapped typek hash mapcKey, T,H,EO,A2::operatorl [(const 
key typek Rk) 
( 


size type i - hash(k)9ob.sizeO; // hasítás 


Jfor(Entry? p - blil; ib -b2nexD keresés a hasítás eredményeképpen i-be került 
// elemek között 
if (eg(k p-2key)) ( // megvan 
if (p-2erased) f // újbóli beszúrás 
b-2erased - false; 
no of erased-; 
return p-xval - default value; 


J 


return p-2val; 


7 


// ha nincs meg 


if (size type(b.sizeO"max load) 7 v.sizeO) f /ha "telített" 
resize(b. size" grow); // növekedés 
return operatorf KR); // újrahasítás 


J 


v.push back(Entry(k, default. value, bli))9; // Entry hozzáadása 
b[i) - gv.backO; // az új elemre mutat 


return bl[ij-2val; 


A map megoldásától eltérően a hash map nem a , kisebb mint" műveletből származtatható 
egyenlőségvizsgálatot (§17.1.4.1) használja, hiszen az azonos hasítókóddal rendelkező ele- 
meket végignéző ciklusban az egŐ függvény meghívása pontosan ezt a feladatot látja el. Ez 
a ciklus nagyon fontos a keresés hatékonysága szempontjából, a leggyakoribb kulcstípusok 
(például a string, vagy a C stílusú karakterláncok) szempontjából pedig egy felesleges 
összehasonlítás akár jelentős teljesítményromlást is eredményezhet. 


Az azonos hasítókóddal rendelkező elemek tárolásához használhattuk volna a setcEntryz 
tárolót is, de ha elég jó hasítófüggvényünk (hashO) van és a hasítótábla (b) mérete is meg- 
felelő, akkor ezen halmazok többségében egyetlen elem lesz. Ezért ezeket az elemeket egy- 


szerűen az Entry osztály next mezőjével kapcsoltam össze (417.8[27D. 


Figyeljük meg, hogy a b az elemekre hivatkozó mutatókat tárolja és az elemek valójában 
a v-be kerülnek. A push backO általában megtehetné, hogy áthelyezi az elemeket, és ezzel 
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a mutatók érvénytelenné válnának (416.3.5), most azonban a konstruktorok (§17.6.2) és 
a resizeO függvény előre helyet foglalnak az elemek számára a reserveO eljárással, így el- 
kerüljük a váratlan áthelyezéseket. 


17.6.2.2. Törlés és átméretezés 


A hasítófüggvényes keresés nagyon rossz hatásfokúvá válhat, ha a tábla túlságosan telített. 
Az ilyen kellemetlenségek elkerülése érdekében az indexelő operátor automatikusan átmé- 
retezheti a táblát. A set loadO (§17.6.2) függvény szabályozza, hogy ez az átméretezés mi- 
kor és hogyan menjen végbe, néhány további függvénnyel pedig lehetővé tesszük a prog- 
ramozó számára, hogy lekérdezze a hash map állapotát: 


templatecxciass Key, class T, class H - HashSKey-, 
class EO - egual tozKey?:, class A - allocators paircconst Key, I: 2 5 
class hash map f 


JI av 
void resize(size type n); // a hasító tábla méretének n-re állítása 
void erase(iterator position); // a mutatott elem törlése 


size type sizeO const f return v.size-no of erased; ) // az elemek száma 


size type bucket countO const f return b.sizeO); ) // a hasító tábla mérete 

Hasher hash funO const f return hash; ) // a használt hasító függvény 
key egual key egO const f return eg; ) // a használt egyenlőségvizsgálat 
VES 


); 


A resizeO függvény rendkívül fontos, viszonylag egyszerű, de néha rendkívül , drága" 
művelet: 


templateccilass Key, class T, class H - HashSKey-, 
class EO - egual tozKey?:, class A - allocators paircconst Key, I: 2 5 
void hash mapcKey, T,H,EO,A:::resize(rsize type 5) 
t 
size type i — v.sizeO; 
while (no. of erased) f // a "törölt" elemek tényleges eltávolítása 
if (-ij.erased) f 
v.erase( uli)); 
--no. of erased; 
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if (s c b.sizeO) return; 


b.resize(5); /7 s-b.size) számű mutató hozzáadása 

Jillr(b.beginO,b.endO,0);  // bejegyzések törlése (§18.6.6) 

v.reserve(s"max. load); // ha v-nek újbóli memóriafoglalásra van szüksége, most 
// történjen meg 

if (no. of erased) ( // a "törölt" elemek tényleges eltávolítása 


for (size type i -— v.sizeO-1; O0€-i; i--) 
if (uliJ.erased) f 
v.erase(e uli)); 
if (-no of erased -—-— 0) break; 


J 
J 
for (size type i — O; izv.sizeO; it1) ( // újrahasítás 
size type ii - hash(1lij.key)9ob.sizeO; // hasítás 
ulil.next — b[iij; // láncolás 
bliij — kulij; 
j 


j 
Ha szükség van rá, a programozó maga is meghívhatja a resizeŐ eljárást, így biztosíthatja, 
hogy az időveszteség kiszámítható helyen következzen be. Tapasztalataim szerint bizonyos 
alkalmazásokban a resizeO művelet rendkívül fontos, de a hasítótáblák szempontjából nem 
nélkülözhetetlen. Egyes megvalósítási módszerek egyáltalán nem használják. 


Mivel a tényleges munka nagy része máshol történik (és csak akkor, amikor átméretezzük 
a hash map tárolót), az erase0 függvény nagyon egyszerű: 


templatexciass Key, class T; class H - HashSKey7, 
class EO - egual tozKey?:, class A - allocators paircconst Key, T2 22 
void hash mapcKey, T,H,EO,A2::erase(iterator p) // a mutatott elem törlése 
t 
if (p-2erased -- false) no of erasedtt; 
b-2erased - true; 


j 


17.6.2.3. Hasítás 


A hash map::operatorf JOÓ teljessé tételéhez még meg kell határoznunk a hashÓ és az egO 
függvényt. Bizonyos okokból (amelyeket majd a §18.4 pontban részletezünk) a hasító függ- 
vényt érdemesebb egy függvényobjektum oberatorOO műveleteként elkészítenünk: 


template class T- struct Hash : unary functioncT; size t ( 
size t oberatorO(const Ik key) const; 


J; 
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A jó hasító függvény paraméterében egy kulcsot kap és egy egész értéket ad vissza, amely 
különböző kulcsok esetében nagy valószínűséggel különböző. A jó hasítófüggvény kivá- 
lasztása nagyon nehéz. Gyakran az vezet elfogadható eredményhez, ha a kulcsot jelölő bi- 
teken és egy előre meghatározott egész értéken , kizáró vagy" műveletet hajtunk végre: 


template class T- size t HashzT5::operatorO(const Ik key) const 


( 


size tres — 0; 


size t len - sizeo(D; 
const char? p - reinterpret castáconst chart-(kkey);  //objektumok elérése bájtok 
// sorozataként 


while (len-) res — (reszcIUNptt; // a kulcsábrázolás bájtjainak használata 
return res; 


J 


A reinterpret cast (§6.2.7) használata jól jelzi, hogy valami , csúnya" dolgot műveltünk, és 
ha többet tudunk a hasított értékről, akkor ennél hatékonyabb megoldást is találhatunk. 
Például, ha az objektum mutatót tartalmaz, ha nagy objektumról van szó, vagy ha az adat- 
tagok igazítása miatt az objektum ábrázolásában felhasználatlan területek (, lyukak", holes) 
vannak, mindenképpen jobb hasítófüggvényt készíthetünk (417.8[29D. 


A C stílusú karakterláncok mutatók (a karakterekre) és a sztring is tartalmaz mutatót. 
A specializációk ezekre az esetekre sorrendben a következők: 


size t Hash£char" -::operator (const char? key) const 


( 


size tres — 0; 


while (key) res - (reszzIN"keytt; // a karakterek egész értékének használata 
return res; 


J 


template cclass C2 
size t HashZ basic stringZC: 5::operator((const basic stringzC-£ key) const 


( 


size t res — 0; 


typedef basic stringZC2::const iterator CI; 
CI p - key.beginO; 
CI end - key.endO; 


while (p/-end) res -— (reszzIUNptr; // a karakterek egész értékének használata 
return res; 
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A hash map minden megvalósításában legalább az egész és a karakterlánc típusú kulcsok- 
hoz szerepelniük kell hasítófüggvénynek. Komolyabb kulcsok esetében a programozót se- 
gíthetjük megfelelő specializációkkal is. A jó hasítófüggvény kiválasztásában sokat segíthet 
a megfelelő mérőszámokra támaszkodó kísérletezés. Megérzéseinkre nagyon ritkán hagyat- 
kozhatunk ezen a területen. 


A hash map akkor válik teljessé, ha bejárókat is definiálunk és néhány további egyszerű 
függvényt is készítünk. Ez azonban maradjon meg feladatnak (§17.8[34D. 


17.6.3. További hasított asszociatív tárolók 


Az egységesség és a teljesség érdekében mindenképpen el kell készítenünk a hash map 
, testvéreit" is: a hash set, a hash multimap és a hash multiset tárolót. Ezek létrehozása 
a hash map, a map, a multimap, a set és a multiset alapján egyszerű, így ezeket is megha- 
gyom feladatnak §17.8[34]. Ezeknek a hasított asszociatív tárolóknak komoly irodalma van 
és kész kereskedelmi változatok is elérhetők belőlük. Tényleges programokban ezek a vál- 
tozatok jobban használhatók, mint a házilag összeeszkábáltak (köztük az általam bemuta- 
tott is). 


17.7. Tanácsok 


[1] Ha tárolóra van szükségünk, általában a vector osztályt használjuk. §17.1. 

[2] Ha gyakran használunk egy műveletet, érdemes ismerni annak költségeit 
(bonyolultság, , nagy 0" mérték) §17.1.2. 

[3] A tároló felülete, megvalósítása és ábrázolása külön-külön fogalom. Ne kever- 
jük össze őket. §17.1.3. 

[4] Keresést vagy rendezést bármilyen szempont szerint megvalósíthatunk. 
§17.1.4.1. 

[5] Ne használjunk kulcsként C stílusú karakterláncokat, vagy biztosítsunk megfele- 
lő összehasonlítási műveletet. §17.1.4.1. 

[6] Az összehasonlítási szemponttal elemek egyenértékűségét határozhatjuk meg, 
ami eltérhet attól, hogy a kulcsok teljesen egyenlők-e. §17.1.4.1. 

[7] Lehetőleg használjuk a sorozat végét módosító függvényeket (back-műveletek), 
ha elemek beszúrására vagy törlésére van szükségünk. §17.1.4.1. 
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Í8] Ha sok beszúrásra, illetve törlésre van szükség a sorozat elején vagy belsejében, 
használjuk a /isz tárolót. 

[9] Ha az elemeket legtöbbször kulcs alapján érjük el, használjuk a map vagy 
a multimap szerkezetet. §17.4.1. 

[10] A lehető legnagyobb rugalmasságot úgy érhetjük el, ha a lehető legkevesebb 
műveletet használjuk. §17.1.1. 

[11] Ha fontos az elemek sorrendje, a hash map helyett használjuk a map osztályt. 
§17.6.1. 

[12] Ha a keresés sebessége a legfontosabb, a hash map hasznosabb, mint a map. 
§17.6.1. 

[13] Ha nem tudunk az elemekre , kisebb mint" műveletet megadni, a hash map 
tárolót használhatjuk. §17.6.1. 

[14] Ha azt akarjuk ellenőrizni, hogy egy kulcs megtalálható-e egy asszociatív tároló- 
ban, használjuk a findO függvényt. §17.4.1.6. 

[15] Ha az adott kulccsal rendelkező összes elemet meg akarjuk találni, használjuk 
az egual rangeO-et. §17.4.1.6. 

[16] Ha ugyanazzal a kulccsal több elem is szerepelhet, használjuk a multimap táro- 
lót. §17.4.2. 

[17] Ha csak a kulcsot kell nyilvántartanunk, használjuk a set vagy a multiset osz- 
tályt. §17.4.3. 


17.8. Gyakorlatok 


Az itt szereplő gyakorlatok többségének megoldása kiderül a standard könyvtár bármely 
változatának forráskódjából. Mielőtt azonban megnéznénk, hogy a könyvtár megalkotói 
hogyan közelítették meg az adott problémát, érdemes saját megoldást készítenünk. Végül 
nézzük át, hogy saját rendszerünkben milyen tárolók és milyen műveletek állnak rendelke- 
zésünkre. 


1. (2.5) Értsük meg az OC ) jelölést (§17.1.2). Végezzünk néhány mérést a szabvá- 
nyos tárolók műveleteire és határozzuk meg a konstans szorzókat. 

2. (2) Sok telefonszám nem ábrázolható egy /ong értékkel. Készítsünk egy 
bhone number típust és egy osztályt, amely meghatározza az összes olyan mű- 
veletet, melyeknek egy telefonszámokat tároló tárolóban hasznát vehetjük. 

3. (2) Írjunk programot, amely kiírja egy fájl szavait ábécésorrendben. Készítsünk 
két változatot: az egyikben a szó egyszerűen üreshely karakterekkel határolt ka- 
raktersorozat legyen, a másikban olyan betűsorozat, melyet nem betű karakte- 
rek sorozata határol. 
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4. (2.5) Írjunk egy egyszerű Pasziánsz kártyajátékot. 

5. (1.5) Írjunk programot, amely eldönti, hogy egy szó palindrom-e (azaz ábrázo- 
lása szimmetrikus-e, például: ada, otto, tap. írjuk eljárást, amely egy egész 
számról dönti el ugyanezt, majd készítsünk mondatokat vizsgáló függvényt. 
Általánosítsunk. 

6. C1.5) Készítsünk egy sort (gueue) két verem segítségével. 

7. G1.5) Készítsünk egy vermet, amely majdnem olyan, mint a stack, csak nem 
másolja az elemeit és lehetővé teszi bejárók használatát. 

8. (3) Számítógépünk minden bizonnyal támogat valamilyen konkurens (párhu- 
zamos végrehajtási) lehetőséget: szálakat (thread), taszkokat (task) vagy folya- 
matokat (process). Derítsük ki, hogyan működik ez. A konkurens hozzáférést 
lehetővé tevő rendszer valamilyen módot ad rá, hogy megakadályozzuk, hogy 
két folyamat ugyanazt a memóriaterületet egyszerre használja. Saját rendszerünk 
zárolási eljárása alapján készítsünk egy osztályt, amely a programozó számára 
egyszerűen elérhetővé teszi ezt a lehetőséget. 

9. (2.5) Olvassuk be dátumok egy sorozatát (például: DecS5, Dec50, Jan 70), 
majd jelenítsük meg azt úgy, hogy a legkésőbbi időpont legyen az első a sor- 
ban. A dátum formátuma a következő legyen: hónapnév három karakteren, 
majd évszám két karakteren. Tételezzük fel, hogy mindegyik dátum ugyanarra 
az évszázadra vonatkozik. 

10. (2.5) Általánosítsuk a dátumok bemeneti formátumát úgy, hogy felismerje az 
alábbi dátumformátumokat: Dec1985, 12/3/1990, (Dec,30,1950), 3/6/20017, stb. 
Módosítsuk a §17.819] feladatot úgy, hogy működjön ezekre a formátumokra is. 

11.C1.5) Használjuk a biítset tárolót néhány szám bináris alakjának kiíratásához. 
Például 0, 7, -1, 18, -18 és a legnagyobb pozitív int érték. 

12.C"1.5) A bitset segítségével ábrázoljuk, hogy egy osztály mely tanulói voltak 
jelen egy adott napon. Olvassuk be 12 nap bíitset objektumát és állapítsuk meg, 
kik voltak jelen minden nap, és kik voltak legalább 8 napot az iskolában. 

13.C"1.5) Készítsünk egy olyan mutatókból álló listát, amely törli a mutatott objek- 
tumokat is, ha egy mutatót törlünk belőle vagy ha az egész listát megszüntetjük. 

14.(C1.5) Írassuk ki rendezve egy adott stack objektum elemeit anélkül, hogy az 
eredeti vermet megváltoztatnánk. 

15. (2.5) Fejezzük be a hash map (§17.6.1) megvalósítását. Ehhez meg kell írnunk 
a findOŐ és az egual rangeO függvényt, valamint módot kell adnunk a kész sab- 
lon ellenőrzésére. Próbáljuk ki a hash map osztályt legalább egy olyan kulcstí- 
pusra, melyre az alapértelmezett hasítófüggvény nem használható. 

16. 2.5) Készítsünk el egy listát a szabványos /ist stílusában és teszteljük. 

17.(C"2) Bizonyos helyzetekben a /ist túlzott memória-felhasználása problémát 
jelent. Készítsünk egy egyirányú láncolt listát a szabványos tárolók stílusában. 
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18. (2.5) Készítsünk el egy listát, amely olyan, mint a szabványos /isz, csak támo- 
gatja az indexelést is. Hasonlítsunk össze néhány listára az indexelés költségét 
egy ugyanilyen méretű vector indexelési költségével. 

19. (2) Készítsünk egy sablon függvényt, amely két tárolót összefésül. 

20.C1.5) Állapítsuk meg, hogy egy C stílusú karakterlánc palindrom-e. Vizsgáljuk 
meg, hogy a karakterlánc (legalább) első három szavából álló sorozat palind- 
rom-e. 

21. C2) Olvassuk be (name, value) (név, érték) párok egy sorozatát és készítsünk 
egy rendezett listát (name, total, mean, median) (név, összesen, átlag, közép- 
érték) sorokból. 

22. C2.5) Vizsgáljuk meg, mekkora az általunk készített tárolók tárigénye. 

23.C3.5) Gondolkozzunk el azon, milyen megvalósítási stratégiát használhatnánk 
egy olyan hash map tárolóhoz, melynél a lehető legkisebb tárigény a legfőbb 
követelmény. Hogyan készíthetnénk olyan hash map osztályt, melynek keresé- 
si ideje minimális? Nézzük át, mely műveleteket érdemes kihagyni a megvalósí- 
tásból az optimálishoz (felesleges memóriafoglalás, illetve időveszteség nélküli) 
közeli megoldás eléréséhez. Segítség: a hasítótábláknak igen kiterjedt irodalma 
van. 

24. 2) Dolgozzunk ki olyan elvet a hash map túlcsordulásának (különböző érté- 
kek ugyanazon hasítókódra kerülésének) kezelésére, amely az egual rangeO 
elkészítését egyszerűvé teszi. 

25.C2.5) Becsüljük meg a hash map tárigényét, majd mérjük is le azt. Hasonlítsuk 
össze a becsült és a számított értékeket. Hasonlítsuk össze az általunk megvaló- 
sított hash map és map tárigényét. 

26.(C2.5) Vizsgáljuk meg saját hash map osztályunkat abból a szempontból, hogy 
melyik művelettel telik el a legtöbb idő. Tegyük meg ugyanezt saját map táro- 
lónkra, illetve a hash map kereskedelmi változataira is. 

27.C2.5) Készítsük el a hash map tárolót egy vectorcmapzK, V2?t: szerkezet segít- 
ségével. Minden map tárolja az összes olyan kulcsot, melyek hasítókódja meg- 
egyezik. 

28.C"3) Készítsük el a hash map osztályt Splay fák segítségével. (Lásd: D. Sleator, 
R. E. Tarjan: Self-Adjusting Binary Search Trees, JACM, 32. kötet, 1985) 

29. 2) Adott egy struktúra, amely egy karakterlánc-szerű egyedet ír le: 


struct St ( 
int size; 
char type indicator; 
char" buf; // méretre mutat 
St(const char? p); // memóriafoglalás és a buf feltöltése 
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Készítsünk 1000 Sz objektumot és használjuk ezeket egy hash map kulcsaként. 
Készítsünk programot, mellyel tesztelni lehet a hash map hatékonyságát. 
írjunk egy hasítófüggvényt (/Hash, §17.6.2.3) kifejezetten az St típusú kulcsok 
kezeléséhez. 

30. (2) Adjunk legalább négyféle megoldást a törlésre kijelölt (erased) elemek eltá- 
volítására a hash map tárolóból. Ciklus helyett használjuk a standard könyvtár 
algoritmusait. (§3.8, 18. fejeze)) 

. 03) Készítsünk olyan hash map tárolót, amely azonnal törli az elemeket. 

. C2) A §17.6.2.3 pontban bemutatott hasítófüggvény nem mindig használja 
a kulcs teljes ábrázolását. Mikor hagy figyelmen kívül részleteket ez a megoldás? 


felti 


5) 
2 


[60] 


írjunk olyan hasítófüggvényt, amely mindig a kulcs teljes ábrázolását használja. 
Adjunk rá példát, mikor lehet jogos a kulcs egy részének , elfelejtése" és írjunk 
olyan hasítófüggvényt, amely a kulcsnak csak azt a részét veszi figyelembe, 
amelyet fontosnak nyilvánítunk. 

33.(€2.5) A hasítófüggvények forráskódja meglehetősen hasonló: egy ciklus sorra 
veszi az adatokat, majd előállítja a hasítóértéket. Készítsünk olyan Hash 
(§17.6.2.3) függvényt, amely az adatokat egy, a felhasználó által megadott függ- 
vény ismételt meghívásával gyűjti össze. Például: 


size t res — 0; 
while (size t v - hash(key)) res -— (reszz3)Nw; 


Itt a felhasználó a has/(K) függvényt minden olyan X típusra megadhatja, amely 
alapján hasítani akar. 

34.(G3) A hash map néhány megvalósításából kiindulva készítsük el 
a hash multimap, a hash setés a hash multiset tárolót. 

35.(t2.5) Készítsünk olyan hasítófüggvényt, amely egyenletes eloszlású int értéke- 
ket képez le egy körülbelül 1024 méretű hasítótáblára. Ezen hasítófüggvény is- 
meretében adjunk meg 1024 olyan kulcsértéket, amelyet a függvény ugyanarra 
a hasítókódra képez le. 
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Algoritmusok és függvényobjektumok 


, A forma szabaddá tesz." 
(a mérnökök közmondása) 


Bevezető e A szabványos algoritmusok áttekintése s Sorozatok s Függvényobjektu- 
mok "e Predikátumok e Aritmetikai objektumok e Lekötők e Tagfüggvény-objektumok e 
Jfor.each s Elemek keresése s count s Sorozatok összehasonlítása s Keresés s Másolás s 
transform s Elemek lecserélése és eltávolítása s Sorozatok feltöltése s Átrendezés e swap ? 
Rendezett sorozatok e binary search s merge s Halmazműveletek e min és max s Kupac e 
Permutációk s C stílusú algoritmusok s Tanácsok s Gyakorlatok 


18.1. Bevezető 


Egy tároló önmagában nem túlságosan érdekes dolog. Ahhoz, hogy tényleg hasznossá vál- 
jon, számos alapvető műveletre is szükség van, melyekkel például lekérdezhetjük a tároló 
méretét, bejárhatjuk, másolhatjuk, rendezhetjük, vagy elemeket kereshetünk benne. Sze- 
rencsére a standard könyvtár biztosítja mindazokat a szolgáltatásokat, melyekre a progra- 
mozóknak szükségük van a tárolók használatához. 
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Ebben a fejezetben a szabványos algoritmusokat foglaljuk össze és néhány példát mutatunk 
be használatukra. Kiemeljük azokat a legfontosabb elveket és módszereket, melyeket is- 
mernünk kell az algoritmusok lehetőségeinek a C--t-ban való kiaknázásához. Néhány alap- 
vető algoritmust részletesen is megvizsgálunk. 


Azokat az eljárásokat, melyek segítségével a programozók saját igényeikhez alakíthatják 
a szabványos algoritmusok viselkedését, a függvényobjektumok biztosítják. Ezek adják 
meg azokat az alapvető információkat is, melyekre a felhasználók adatainak kezeléséhez 
szükség van. 


Éppen ezért nagy hangsúlyt helyezünk arra, hogy bemutassuk a függvényobjektumok lét- 
rehozásának és használatának módszereit. 


18.2. A standard könyvtár algoritmusainak áttekintése 


Első pillantásra úgy tűnhet, hogy a standard könyvtár algoritmusainak száma szinte végte- 
len, pedig ,mindössze" 60 darab van belőlük. Találkoztam már olyan osztállyal, melynek 
önmagában több tagfüggvénye volt. Ráadásul nagyon sok algoritmus ugyanazt az általános 
viselkedésformát, illetve felületstílust mutatja, és ez nagymértékben leegyszerűsíti megérté- 
süket. Ugyanúgy, mint a programnyelvi lehetőségek esetében, a programozónak itt is csak 
azokat az elemeket kell használnia, amelyekre éppen szüksége van és amelyek működését 
ismeri. Semmilyen előnyt nem jelent, ha minden aprósághoz szabványos algoritmust kere- 
sünk, és azért sem kapunk jutalmat, ha az algoritmusokat rendkívül , okosan", de áttekint- 
hetetlenül alkalmazzuk. Ne felejtsük el, hogy a programkód leírásának elsődleges célja, 
hogy a későbbi olvasók számára a program működése érthető legyen (A , későbbi olvasók" 
valószínűleg mi magunk leszünk néhány év múlva.) Másrészt, ha egy tároló elemeivel va- 
lamilyen feladatot kell elvégeznünk, gondoljuk végig, hogy a művelet nem fogalmazható-e 
meg a standard könyvtár algoritmusainak stílusában. Az is elképzelhető, hogy az algoritmus 
már meg is van, csak olyan általános formában, hogy első ránézésre rá sem ismerünk. Ha 
megszokjuk az általánosított (generikus) algoritmusok világát, nagyon sok felesleges mun- 
kától kímélhetjük meg magunkat. 
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Mindegyik algoritmus egy sablon függvény (template function) (413.3) formájában jelenik 
meg vagy sablon függvények egy csoportjaként. Ez a megoldás lehetővé teszi, hogy az al- 
goritmusok sokféle elemsorozaton legyenek képesek működni és természetesen az elemek 
típusa is módosítható legyen. Azok az algoritmusok, melyek eredményképpen egy bejárót 
CGterator) (419.1) adnak vissza, általában a bemeneti sorozat végét használják a sikertelen 
végrehajtás jelzésére: 


void ((listsstring:€£ ls) 
í 


listsstring3::const iterator p — find(is.beginO,ls.endO, "Frici"; 


if (p —— ls.endO) (f 
// "Frici" nem található 
) 
else ( 
// bp "Frici"-re mutat 
) 
j 


Az algoritmusok nem végeznek tartományellenőrzést a be- vagy kimenetükön. A rossz 
tartományból eredő hibákat más módszerekkel kell elkerülnünk (418.3.1, §19.3) Ha az algo- 
ritmus egy bejárót ad vissza, annak típusa ugyanolyan lesz, mint a bemeneti sorozat vala- 
melyik bejárójának. Tehát például az algoritmus paramétere határozza meg, hogy a vissza- 
térési érték const iterator vagy nem konstans iterator lesz-e: 


void fK(listsint-£ li, const listsstring:€ is) 


í 
listsint:::iterator p — find(li.beginO, li.endO, 429; 
listsstring:::const iterator g — findds.beginO,ls.endO, "Ring"; 


J 


A standard könyvtár algoritmusai között megtaláljuk a tárolók leggyakoribb általános mű- 
veleteit, például a bejárásokat, kereséseket, rendezéseket, illetve az elemek beszúrását és 
törlését is. A szabványos algoritmusok kivétel nélkül az szd névtérben találhatók és az 
algorithm? fejállomány deklarálja őket. Érdekes, hogy az igazán általános algoritmusok 
nagy része annyira egyszerű, hogy általában helyben kifejtett (inline) sablon függvények 
valósítják meg azokat. Ezért az algoritmusok ciklusait a hatékony, függvényen belüli 
optimalizációs eljárások jelentősen javíthatják. 


A szabványos függvényobjektumok is az szid névtérben találhatók, de ezek deklarációját 
a Cfunctional: fejállományban érhetjük el. A függvényobjektumok felépítése is olyan, hogy 
könnyen használhatók helyben kifejtett függvényként. 
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A nem módosító sorozatműveletek arra használhatók, hogy adatokat nyerjünk ki egy soro- 
zatból vagy bizonyos elemek helyét meghatározzuk bennük: 





Nem módosító sorozatműveletek (818.5) calgorithm— 








Jfor. each Művelet végrehajtása egy sorozat összes elemére. 

findO Egy érték első előfordulásának megkeresése egy 
sorozatban. 

find if0 Az első olyan elem megkeresése egy sorozatban, amire 


egy állítás teljesül. 
find first ofO Egy sorozat egy elemének megkeresése egy másik 


sorozatban. 

adjacent findO Két szomszédos érték keresése. 

countO Egy érték előfordulásainak száma egy sorozatban. 

count ifO Azon elemek száma egy sorozatban, melyre teljesül egy 
állítás. 

mismatchO Az első olyan elemek keresése, ahol két sorozat 
különbözik. 

egualÓ Igazat ad vissza, ha két sorozat elemei páronként meg- 
egyeznek. 

searchO Egy sorozat első előfordulását keresi meg 
részsorozatként. 

find endŐ Egy sorozat részsorozatként való utolsó előfordulását 
keresi meg. 

search n0 Egy érték n-edik előfordulását keresi meg egy sorozatban. 











A legtöbb algoritmus lehetővé teszi, hogy a programozó határozza meg azt a feladatot, ame- 
lyet minden elemen, illetve elempáron el akar végezni. Ezáltal az algoritmusok sokkal álta- 
lánosabbak és hasznosabbak, mint azt első ránézésre gondolhatnánk. A programozó hatá- 
rozhatja meg, mikor tekintünk két elemet azonosnak és mikor különbözőnek (418.4.2), és 
a leggyakrabban végrehajtott, leghasznosabb műveletet alapértelmezettként is kijelölheti. 


A sorozatmódosító műveletek között igen kevés hasonlóságot találhatunk azon kívül, hogy 
megváltoztatják a sorozat egyes elemeinek értékét: 
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Sorozatmódosító műveletek (818.6) calgorithm— 











transformO 
copyO 

copy backwardO 
swapO 

iíter swapO 
swap rangesO 
replaceO 

replace ifO 
replace copyO 


replace copy ifO 


Jillo 
filLnO 


generateO 
generate n0 


removeO 
remove ifO 
remove copyO 
remove copy ifO 
unigueO 

unigue copyO 


reverseO 

reverse copyO 
rotateO 

rotate copyO 
random shujffleO 


Művelet végrehajtása a sorozat minden elemén. 
Sorozat másolása az első elemtől kezdve. 
Sorozat másolása az utolsó elemtől kezdve. 

Két elem felcserélése. 

Bejárók által kijelölt két elem felcserélése. 

Két sorozat elemeinek felcserélése. 

Adott értékű elemek helyettesítése. 

Állítást kielégítő elemek helyettesítése. 

Sorozat másolása adott értékű elemek 
helyettesítésével. 

Sorozat másolása állítást kielégítő elemek 
helyettesítésével. 

Az összes elem helyettesítése egy adott értékre. 
Az első n elem helyettesítése egy adott értékkel. 
Az összes elem helyettesítése egy művelettel előállí- 
tott értékre. 

Az első n elem helyettesítése egy művelettel előállí- 
tott értékre. 

Adott értékkel rendelkező elemek törlése. 
Állítást kielégítő elemek törlése. 

Sorozat másolása adott értékű elemek törlésével. 


Sorozat másolása állítást kielégítő elemek törlésével. 


Szomszédos egyenértékű elemek törlése. 

Sorozat másolása szomszédos egyenértékű elemek 
törlésével. 

Az elemek sorrendjének megfordítása. 

Elemek másolása fordított sorrendben. 

Elemek körbeforgatása. 

Sorozat másolása az elemek körbeforgatásával. 
Elemek átrendezése egyenletes eloszlás szerint. 
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Minden jó rendszer magán viseli megalkotójának érdeklődési körét, illetve személyes jel- 
lemvonásait. A standard könyvtár tárolói és algoritmusai tökéletesen tükrözik a klasszikus 
adatszerkezetek mögötti elveket és az algoritmusok tervezési szempontjait. A standard 
könyvtár nem csak a tárolók és algoritmusok legalapvetőbb fajtáit biztosítja, melyekre min- 
den programozónak szüksége van, hanem olyan eszközöket is, melyekkel ezek az algorit- 


musok megvalósíthatók, és lehetőséget ad a könyvtár bővítésére is. 
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A hangsúly most nem igazán azon van, hogy ezek az algoritmusok hogyan valósíthatók 
meg, sőt — a legegyszerűbb algoritmusoktól eltekintve — nem is azok használatán. Ha az al- 


goritmusok szerkezetéről és elkészítési módjairól többet szeretnénk megtudni, más köny- 
veket kell fellapoznunk (például IKnuth, 1968] vagy [Tarjan, 1983]. Itt azzal foglalkozunk, 
mely algoritmusok állnak rendelkezésünkre a standard könyvtárban és ezek hogyan jelen- 
nek meg a C-t nyelvben. Ez a nézőpont lehetővé teszi, hogy — amennyiben tisztában va- 
gyunk az algoritmusokkal — hatékonyan használjuk a standard könyvtárat, illetve olyan 


szellemben fejlesszük azt tovább, ahogy megszületett. 


A standard könyvtár sok-sok olyan eljárást kínál, melyekkel sorozatokat rendezhetünk, ke- 


reshetünk bennük, vagy más, sorrenden alapuló műveleteket végezhetünk velük: 





Rendezett sorozatok műveletei (818.7) calgorithm— 








sortO 
stable sortO 


bartial sortO 
bartial sort copyO 
nth elementO 
lower. boundO 
upper. boundO 
egual rangeO 
binary searchO 


mergeO 
inplace mergeO 


bartitionO 


stable partitionO 





Átlagos hatékonysággal rendez. 

Az egyenértékű elemek sorrendjének megtartásával 
rendez. 

Egy sorozat elejét rendezi. 

Másol a sorozat elejének rendezésével. 

Az n-edik elemet a megfelelő helyre teszi. 

Egy érték első előfordulását keresi meg. 

Egy érték utolsó előfordulását keresi meg. 

Egy adott értéket tartalmazó részsorozatot ad meg. 
Igazat ad vissza, ha a megadott érték szerepel 

a sorozatban. 

Két rendezett sorozatot fésül össze. 

Két egymást követő rendezett részsorozatot fésül 
össze. 

Elemeket helyez el egy állításnak (feltételnek) 
megfelelően. 

Elemeket helyez el egy állításnak megfelelően, 

a relatív sorrend megtartásával. 
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Halmazműveletek (818.7.5) calgorithm— 








includesO Igazat ad vissza, ha egy sorozat részsorozata 
egy másiknak. 

set union Rendezett uniót állít elő. 

set intersectionO Rendezett metszetet állít elő. 

set differenceO Azon elemek rendezett sorozatát állítja elő, 


melyek az első sorozatban megtalálhatók, de 
a másodikban nem. 

set symmetric difference0 Azon elemek rendezett sorozatát állítja elő, me- 
lyek csak az egyik sorozatban találhatók meg. 











A kupacműveletek (heap-műveletek) olyan állapotban tartják a sorozatot, hogy az könnyen 
rendezhető legyen, amikor arra szükség lesz: 





Kupacműveletek (818.8) calgorithm— 








make heapO Egy sorozatot felkészít kupacként való használatra. 
bush heapO Elemet ad a kupachoz. 

bop heapO Elemet töröl a kupacból. 

sort heapO Rendezi a kupacot. 











A könyvtár biztosít néhány olyan eljárást is, melyek összehasonlítással kiválasztott eleme- 


ket adnak meg: 





Minimum és maximum (818.9) calgorithm—: 








minO Két érték közül a kisebb. 

maxO Két érték közül a nagyobb. 

min elementO A legkisebb érték egy sorozatban. 
max elementO A legnagyobb érték egy sorozatban. 


lexicographical compareO  Kétsorozat közül az ábécésorrend szerint 
korábbi. 
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Végül a könyvtár lehetővé teszi azt is, hogy előállítsuk egy sorozat permutációit (az elemek 
összes lehetséges sorrendjéD: 





Permutációk (818.10) calgorithm— 








next permutationO Az ábécésorrend szerinti rendezés alapján követ- 
kező permutáció. 

brev permutationO Az ábécésorrend szerinti rendezés alapján előző 
permutáció. 











Ezeken kívül, a cnumeric: (§22.6) fejállományban néhány általános matematikai algorit- 
must is találhatunk. 


Az algoritmusok leírásában a sablonparaméterek neve nagyon fontos. Az In, Out, For, Bi és 
Ran elnevezések sorrendben bemeneti bejárót, kimeneti bejárót, előre haladó bejárót, két- 
irányú bejárót, illetve közvetlen elérésű (véletlen elérésű) bejárót jelentenek (§19.2.1. 
A Pred egyparaméterű, a BinPred kétparaméterű predikátumot (állítást, logikai értékű 
függvényt, §18.4.2) határoz meg, míg a Cmp összehasonlító függvényre utal. Az Op egy- 
operandosú műveletet, a BinOp kétoperandosút vár. A hagyományok szerint sokkal 
hosszabb neveket kellett volna használnom a sablonparaméterek megnevezésére, de úgy 
vettem észre, hogy ha már egy kicsit is ismerjük a standard könyvtárat, a hosszú nevek in- 
kább csak rontják az olvashatóságot. 


A közvetlen elérésű bejárók használhatók kétirányú bejáróként is, a kétirányú bejárók előre 
haladó bejáróként, az előre haladó bejárók pedig akár bemeneti, akár kimeneti bejáróként 
(§19.2.10. Ha a sablonnak olyan típust adunk át, amely nem biztosítja a szükséges művelete- 
ket, a sablon példányosításakor hibaüzenetet kapunk (4C.13.79. Ha olyan típust használunk, 
amelyben megvannak a szükséges műveletek, de jelentésük (szerepük) nem a megfelelő, 
akkor kiszámíthatatlan futási idejű viselkedésre kell felkészülnünk (§17.1.49. 
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18.3. Sorozatok és tárolók 


Általános szabály, hogy mindennek a leggyakoribb felhasználási módja legyen a legrövi- 
debb, a legegyszerűbb és a legbiztonságosabb. A standard könyvtár az általánosság érde- 
kében itt-ott megsérti ezt a szabályt, de egy szabványos könyvtár esetében az általánosság 
mindennél fontosabb. A 42 első két előfordulását egy sorozatban például az alábbi prog- 
ramrészlettel kereshetjük meg 


void f(listzint-£k li) 
í 
listsint:::iterator p — finddli.beginO, li.endO, 429; // első előfordulás 
if (p !- li.endO) ( 
listsint:::iterator g - find(xp,li.endO, 429); . // második előfordulás 
V/ASSS 


lé sssze 


Mivel a findO egy tárolókon működő művelet, valamilyen további eszköz segítségével le- 
hetővé kell tennünk, hogy a második előfordulást is elérhessük. A , további eszköz" fogal- 
mát általánosítani minden tárolóra és algoritmusra nagyon nehéz lenne, ezért a standard 
könyvtár algoritmusai csak sorozatokon működnek. Az algoritmusok bemenetét gyakran 
egy bejáró-pár adja, amely egy sorozatot határoz meg. Az első bejáró az első elemet jelöli 
ki, míg a második az utolsó utáni elemet (43.8, §19.2). Az ilyen sorozatot , félig nyíltnak" ne- 
vezzük, mivel az első megadott elemet tartalmazza, de a másodikat nem. A félig nyílt soro- 
zatok lehetővé teszik, hogy a legtöbb algoritmusnak ne kelljen egyedi esetként kezelnie az 
üres sorozatot. 


Egy sorozatot gyakran tekinthetünk tartománynak (range) is, főleg ha elemeit közvetlenül 
elérhetjük. A félig nyílt tartományok hagyományos matematikai jelölése az /első, utolsó) 
vagy az felső, utolsól. Fontos, hogy egy ilyen sorozat lehet tároló vagy annak részsorozata 
is, de bizonyos sorozatok, például a ki- és bemeneti adatfolyamok, egyáltalán nem kapcso- 
lódnak tárolókhoz. A sorozatokkal kifejezett algoritmusok mindegyik esetben tökéletesen 
működnek. 
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18.3.1. Bemeneti sorozatok 


Az x.beginO), x.endŐ párral gyakran jelöljük azt, hogy az x összes elemére szükségünk van, 
pedig ez a jelölés hosszadalmas, ráadásul sok hibalehetőséget hordoz magában. Például ha 
több bejárót is használunk, nagyon könnyen hívunk meg egy algoritmust sorozatot nem al- 
kotó paraméterpárral: 


void f(listsstring:£ fruit, listsstring2£ citrus) 


( 


typedef listsstring:::const iterator LI; 


LIp1 - find(fruit.beginO, citrus.endO, "alma"; // helytelen! (különböző sorozatok) 
LI p2 - find(fruit.beginO, fruit.endO, "alma"; // rendben 

LI p3 - findCcitrus.beginO, citrus.endO, "körte"; // rendben 

LI p4 - find(p2.p3, peach"),; // helytelen! (különböző sorozatok) 
Más 


A példában két hiba is szerepel. Az első még elég nyilvánvaló (főleg ha várjuk a hibán, de 
a fordító már ezt sem könnyen találja meg. A második hibát viszont egy valódi programban 
nagyon nehéz felderíteni, még egy gyakorlott programozó számára is. Ha a bejárók számát 
sikerül csökkentenünk, akkor ezen hibák előfordulásának valószínűségét is csökkenthet- 
jük. Az alábbiakban körvonalazunk egy megközelítést, amely a bemeneti sorozatok fogal- 
mának bevezetésével ezt a problémát próbálja megoldani. Az algoritmusok későbbi bemu- 
tatásakor azonban nem használjuk majd a bemeneti sorozatokat, mert azok a standard 
könyvtárban nem szerepelnek, és ebben a fejezetben kizárólag a standard könyvtárral aka- 
runk foglalkozni. 


Az alapötlet az, hogy paraméterként egy sorozatot adunk meg: 


templatecxclass In, class T2 In finddín first, In last, const Ik v) // szabványos 
( 

while (first!-last k.£ "first/-v) 4--first; 

return first; 


J 


templatecciass In, class T- In find(segzIn: r, const Ik v) // bővítés 


( 


return find(r first, r.second, v); 


j 


A túlterhelés Coverloading) (413.3.2) általában lehetővé teszi, hogy az algoritmus bemeneti 
sorozat formáját használjuk, ha Iseg paramétert adunk át. 
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A bemeneti sorozatot természetesen bejáró-párként (417.4.1.2) valósítjuk meg: 


templatexclass In: struct Iseg : public pairsIn In: f 
Isegdn il, In i2) : pairsln Inx(i1,i2) (1 ? 
j; 


A findŐ függvény második változatának használatához közvetlenül is előállíthatunk Iseg 
bemeneti sorozatot: 


LI p - finddsegzLIe(fruit.beginO fruit.endO), "alma"; 


Ez a megoldás azonban még körülményesebb, mint az eredeti findO függvény. Ahhoz, 
hogy ennek a megoldásnak hasznát vehessük, még egy egyszerű segédfüggvényre van 
szükség. Egy tárolóhoz megadott /seg valójában nem más, mint az elemek sorozata az első- 
től (beginO) az utolsóig (endO).: 


templatexclass C2 IsegZC:riterator: iseg(C£ c) // tárolóra 


( 


return Iseg£C::iterator:(c.beginO,c.endO; 
J 


Ez a függvény lehetővé teszi, hogy a teljes tárolókra vonatkozó algoritmusokat tömören, is- 
métlések nélkül írjuk le: 


void (f((listsstring:€£ ls) 

f 
listsstring:::iterator p - finddis.beginO,Is.endO, "szabványos"; 
listsstring:::iterator g - find (isegdis), "bővítés"; 
Ms 

j 


Az isegŐ függvénynek könnyen elkészíthetjük olyan változatait is, amelyek tömbökhöz, 
bemeneti adatfolyamokhoz, vagy bármely más tárolóhoz (418.13I6D nyújtanak ilyen hozzá- 
férést. 


Az Iseg legfontosabb előnye, hogy a bemeneti sorozat lényegét világossá teszi. Gyakorlati 
haszna abban áll, hogy az isegÖ megszünteti a kényelmetlen és hibalehetőséget magában 
hordozó ismétlődést, amelyet a bemeneti sorozat két bejáróval való megadása jelent. 


A kimeneti sorozat fogalmának meghatározása szintén hasznos lehet, bár kevésbé egysze- 
rű és kevésbé közvetlenül használható, mint a bemeneti sorozatok (418.13[7], lásd még: 
§19.2.49. 
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18.4. Függvényobjektumok 


Nagyon sok olyan algoritmus van, amely a sorozatokat csak bejárók és értékek segítségé- 
vel kezeli. A 7első előfordulását egy sorozatban például az alábbi módon találhatjuk meg: 


void f(listzint2k c) 


( 
listzint:::iterator p — find(c.beginO,c.endO, 79; 
TS 
j 
Egy kicsit érdekesebb eset, ha mi adunk meg egy függvényt, amelyet az algoritmus használ 


(43.8.4). Az első, hétnél kisebb elemet például a következő programrészlet keresi meg: 


bool less than 7(Gint v) 


( 


return v£ 7; 


j 


void fddistizint-£k c) 
( 


listzint:::iterator p — find if(c.beginO,c.endO, less than 79; 
Mae 


J/ 


Nagyon sok egyszerű helyzetben nyújtanak segítséget a paraméterként átadott függvények: 
logikai feltételként (predikátum), aritmetikai műveletként, olyan eljárásként, mellyel infor- 
mációt nyerhetünk ki az elemekből stb. Nem szokás és nem is hatékony minden felhaszná- 
lási területre külön függvényt írni. Másrészt egyetlen függvény néha nem is képes megva- 
lósítani igényeinket. Gyakran előfordul például, hogy a minden egyes elemre meghívott 
függvénynek a lefutások között meg kell tartania valamilyen információt. Az osztályok tag- 
függvényei az ilyen feladatokat jobban végre tudják hajtani, mint az önálló eljárások, hiszen 
az objektumok képesek adatok tárolására és lehetőséget adnak azok kezdeti értékének be- 
állítására is. 


Nézzük, hogyan is készíthetünk egy függvényt — vagy pontosabban egy függvényszerű osz- 
tályt — egy összegzéshez: 


templatexciass T- class Sum f 
T res; 

bublic: 
Sum(T i — 0) : res(i) ( ) // kezdeti értékadás 
void operator((T x) ( res 47 x; ) // összegzés 
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T resultÓ const f return res; ) // összegzés visszaadása 
J; 
Látható, hogy a Sum osztály olyan aritmetikai típusokhoz használható, melyek kezdőérté- 
ke nulla lehet és alkalmazható rájuk a 4- művelet: 


void f(listzdoublezk ld) 


( 
Sumcdouble: s; 
s - for. each(Id.beginO, Id.endO, 59; // 50 meghívása ld minden elemére 
cout 2 "Az összeg: " c£ s.resultÓ cz MM; 

J 


Ebben a programrészletben a for eachO (§18.5.1) függvény az [d minden egyes elemére 
meghívja a Sumzdouble:::operatorO(double) tagfüggvényt, és eredményül a harmadik pa- 
raméterben megadott objektumot adja vissza. 


Annak, hogy ez az utasítás egyáltalán működik, az az oka, hogy a for. eachO nem teszi kö- 
telezővé, hogy harmadik paramétere tényleg egy függvény legyen. Mindössze annyit felté- 
telez, hogy ez a valami meghívható a megfelelő paraméterrel. Ezt a szerepet egy meghatá- 
rozott objektum is betöltheti, sokszor hatékonyabban is, mint egy egyszerű függvény. Egy 
osztály függvényhívó operátorát például könnyebb optimalizálni, mint egy függvényt, me- 
lyet függvényre hivatkozó mutatóként adtunk át. Ezért a függvényobjektumok gyakran 
gyorsabban futnak, mint a szokásos függvények. Azon osztályok objektumait, melyekhez 
elkészítettük a függvényhívó operátort (411.9), függvényszerű objektumoknak, funktorok- 
nak (functor) vagy egyszerűen függvényobjektumoknak nevezzük. 


18.4.1. Függvényobjektumok bázisosztályai 


A standard könyvtár számos hasznos függvényobjektumot kínál. A függvényobjektumok el- 
készítésének megkönnyítéséhez a könyvtár két bázisosztályt tartalmaz: 


template cclass Arg, class Resz struct unary function f 
typedef Arg argument type; 
typedef Res result type; 

j; 


template cclass Arg, class Arg2, class Resz struct binary function f 
typedef Arg first argument type; 
typedef Arg2 second argument type; 
typedef Res result type; 

J; 
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Ezen osztályok célja, hogy szabványos neveket adjanak a paramétereknek és a visszatérési 
érték típusának, így a unary function és a binary function osztály leszármazottait haszná- 
ló programozók elérhetik azokat. A standard könyvtár következetesen használja ezeket az 
osztályokat, ami abban is segíti a programozót, hogy megállapítsa, mire is jó az adott függ- 
vényobjektum (418.4.4.1). 


18.4.2. Predikátumok 


A predikátum Cállítás, feltétel; predicate) egy olyan függvényobjektum (vagy függvény), 
amely logikai (bool értéket ad vissza. A Sfunctional: fejállományban például az alábbi de- 
finíciókat találhatjuk: 


template Sclass T- struct logical not : public unary functionzT;bool: f 
bool operator (const Ig x) const f( return Ix; ? 


J; 


template Sclass T- struct less : public binary functionzT;T,bool: f 


bool operatorO(const Ik x, const Ik y) const f return x2y; ) 


J; 


Az egy- és kétoperandosú (unáris/bináris) predikátumokra gyakran van szükség a szabvá- 
nyos algoritmusok esetében. Például összehasonlíthatunk két sorozatot úgy, hogy megke- 
ressük az első elemet, amely az egyik sorozatban nem kisebb, mint a neki megfelelő elem 
a másikban: 


void fwvectorcint:g vi, listsint:k li) 


( 
typedef listzint:::iterator LI; 
typedef vectorsint:::iterator VI; 
PairSVI,LI- p1 - mismatch(vi.beginO, vi.endO, li.beginO, lesszint20); 
1 aa; 


J 


A mismatchO függvény a sorozatok összetartozó elemeire alkalmazza a megadott 
kétoperandusú predikátumot, mindaddig, amíg az igaz értéket nem ad vissza (§18.5.4). 
A visszatérési érték az a két bejáró, amelyeket az összehasonlítás nem összetartozónak ta- 
lált. Mivel nem típust, hanem objektumot kell átadnunk, a lesscint20 kifejezést használjuk 
CzárójelekkeD a lesscint: forma helyett. 
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Elképzelhető, hogy az első olyan elem helyett, amely nem kisebb a párjánál, pont arra van 
szükségünk, amely kisebb annál. Ezt a feladatot az első olyan elempár megkeresésével végez- 
hetjük el, amelyre a nagyobb vagy egyenlő (greater. egua) kiegészítő feltétel nem teljesül: 


b1 - mismatch(vi.beginO, vi.endO, li.beginO, greater. egualzint20); 


Egy másik lehetőség, hogy a sorozatokat fordított sorrendben adjuk meg és a kisebb vagy 
egyenlő (less eguaD műveletet használjuk: 


pPairzLI, VI: p2 - mismatch(li.beginO, li.endO, vi.beginO, less egualsint209; 


A §18.4.4.4 pontban azt is megnézzük, hogyan írhatjuk le közvetlenül a , nem kisebb" feltételt. 


18.4.2.1. A predikátumok áttekintése 


A cfunctionalt: fejállományban néhány általános predikátum található: 











Predikátumok cfunctionalz 
egual to bináris arg1-—arg2 
not egual to bináris arg1!—arg2 
greater bináris arg1l3arg2 
less bináris arg1carg2 
greater. egual bináris arg15—arg2 
less egual bináris arg1c-arg2 
logical and bináris argixgarg2 
logical or bináris arg11 larg2 
logical not unáris larg 











Az unáris egyparaméterű, a bináris kétparaméterű függvényt jelent, az arg (argumentum) 
a paramétereket jelöli. A less és a logical not műveletet a §18.4.2 pont elején írtuk le. 


A könyvtár által kínált predikátumokon kívül a programozó saját maga is létrehozhat ilyen 
függvényeket. Ezek a programozó által megadott predikátumok nagy szerepet játszanak 
a standard könyvtár algoritmusainak egyszerű és elegáns használatában. A predikátumok 
meghatározásának lehetősége különösen fontos akkor, ha olyan osztályra akarunk használ- 
ni egy algoritmust, amely teljesen független a standard könyvtártól és annak algoritmusai- 
tól. Például képzeljük el a §10.4.6 pontban bemutatott Club osztály következő változatát: 
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class Person €(/£ ... "72; 


struct Club f 
string name; 
listcPerson?: members; 
listzPersont5 officers; 


jö 


Club(const stringk n); 


Igen logikus feladat lenne, hogy megkeressünk egy adott nevű klubot egy /istcClub: táro- 
lóban. A standard könyvtár find ifO algoritmusa azonban egyáltalán nem ismeri a Club 
osztályt. A könyvtári algoritmusok tudják, hogyan lehet egyenlőséget vizsgálni, de a klubot 
mi nem a teljes értéke alapján akarjuk megtalálni, mindössze a Club::name adattagot akar- 
juk kulcsként használni. Tehát írunk egy olyan predikátumot, amely ezt a feltételt tükrözi: 


class Club eg : public unary functionzcilub, bool: f 
string S; 
bublic: 
explicit Club eg(const stringé ss) : s(ss) ( ? 
bool operator (const Clubg c) const f( return c.name--s; ) 


Hő 


A megfelelő predikátumok meghatározása általában nagyon egyszetű, és ha az általunk lét- 
rehozott típusokhoz megadtuk a megfelelő predikátumokat, akkor ezekre a szabványos al- 


goritmusok ugyanolyan egyszerűen és hatékonyan használhatók lesznek, mint az egyszerű 
típusokból felépített tárolók esetében: 


void fistzClub:£ lc) 


( 
typedef listzClub:::iterator LCI; 
LICI p - find ifllc.beginO lc.endO, Club eg("Étkező filozófusok"); 
zés 


j 


18.4.3. Aritmetikai függvényobjektumok 


Amikor numerikus osztályokat használunk, gyakran van szükségünk a szokásos aritmetikai 
műveletekre függvényobjektumok formájában. Ezért a Sfunctional: állományban a követ- 
kező műveletek deklarációja is szerepel: 
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Aritmetikai műveletek cfunctionalz 
blus bináris arg1targ2 
minus bináris arg1—arg2 
multiplies bináris arg1"arg2 
divides bináris arg1/arg2 
modulus bináris arg190arg2 
negate unáris —arg 











A multiplies műveletet használhatjuk például arra, hogy két vector elemeit összeszorozzuk 
és ezzel egy harmadik vektort hozzunk létre: 


void discount(vectorcdoublez£ a, vectorcdoublez£ b, vectorcdoublezk res) 


( 
transform(a.beginO, a.endO, b.beginO, back inserter(res), multiplieszdoublez 9; 


J 


A back inserterŐ eljárásról a §19.2.4. pontban lesz szó. Az aritmetikai algoritmusok néme- 
lyikével a §22.6 fejezetben részletesen foglalkozunk. 


18.4.4. Lekötők, átalakítók és tagadók 


Használhatunk olyan predikátumokat és aritmetikai függvényobjektumokat is, melyeket mi 
magunk írtunk, de hivatkozunk bennük a standard könyvtár által kínált eljárásokra. Ha azon- 
ban egy új predikátumra van szükségünk, előállíthatjuk azt egy már létező predikátum apró 
módosításával is. A standard könyvtár támogatja a függvényobjektumok ilyen felépítését: 
§18.4.4.1 A lekötők (binder) lehetővé teszik, hogy egy kétparaméterű függvényob- 
jektumot egyparaméterű függvényként használjuk, azáltal, hogy az egyik 
paraméterhez egy rögzített értéket kötnek. 
§18.4.4.2 A tagfüggvény-átalakítók (member function adapter) lehetővé teszik, 
hogy tagfüggvényeket használjunk az algoritmusok paramétereként. 
§18.4.4.3 A függvényre hivatkozó mutatók átalakítói (pointer to function adapter) 
lehetővé teszik, hogy függvényre hivatkozó mutatókat használjunk algo- 
ritmusok paramétereként. 
118.4.4.4 A tagadók (negater) segítségével egy állítás (predikátum) tagadását, 
ellentétét (negáltjáb) fejezhetjük ki. 


Ezeket a függvényobjektumokat együtt átalakítóknak (adapter) nevezzük. Mindegyik áta- 


lakító azonos felépítésű és a unary function és binary function függvényobjektum-bázis- 
osztályokon (§18.4.1) alapul. Mindegyikhez rendelkezésünkre áll egy segédfüggvény, mely 
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paraméterenként egy függvényobjektumot kap és a megfelelő függvényobjektumot adja 
vissza. Ha ezeket az osztályokat az obperatorOO művelettel hívjuk meg, akkor a kívánt fel- 
adat kerül végrehajtásra. Tehát az átalakító egyszerűen egy magasabb szintű függvény: egy 
függvényt kap paraméterként és ebből egy másik függvényt állít elő: 





Lekötők, átalakítók, tagadók cfunctional— 





bind2ndO0) binder2nd Kétparaméterű függvény meg- 
hívása úgy, hogy ya második 
paraméter. 
bind1st(x) binder1st Kétparaméterű függvény meg- 
hívása úgy, hogy x az első pa- 
raméter. 
mem funO mem fun t Paraméter nélküli tagfüggvény 
meghívása mutatón keresztül. 
mem fun1 t Egyparaméterű tagfüggvény 
meghívása mutatón keresztül. 
const mem fun t Paraméter nélküli konstans 


tagfüggvény meghívása muta- 
tón keresztül. 


const mem fun1 t Egyparaméterű konstans tag- 
függvény meghívása mutatón 
keresztül. 
mem fun refO mem fun-reft Paraméter nélküli tagfüggvény 


meghívása referencián keresz- 
tül. 

mem funi1 ref t Egyparaméterű tagfüggvény 
meghívása referencián keresz- 
tül. 

const mem fun ref t Paraméter nélküli konstans 
tagfüggvény meghívása 
referencián keresztül. 

const mem fun1 ref t Egyparaméterű konstans tag- 
függvény meghívása referen- 
cián keresztül. 


btr. funO bointer to unary function Egyparaméterű függvényre 
hivatkozó mutató meghívása. 

bir. funO Pbointer to binary function Kétparaméterű függvényre 
hivatkozó mutató meghívása. 

not10 unary negate Egyparaméterű predikátum 
negálása. 

not20 binary negate Kétparaméterű predikátum 


negálása. 
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18.4.4.1. Lekötők 


Az olyan kétparaméterű predikátumok, mint a less (§18.4.2), igen hasznosak és rugalmasak. 
Gyakran tapasztaljuk azonban, hogy a legkényelmesebb predikátum az lenne, amely 
a tároló minden elemét ugyanahhoz a rögzített elemhez hasonlítaná. A §18.4. pontban be- 
mutatott less than 70 egy jellemző példa erre. A less műveletnek mindenképpen két para- 
métert kell megadnunk minden egyes híváskor, így közvetlenül nem használhatjuk ezt az 
eljárást. A megoldás a következő lehet: 


template Sclass T- class less than : public unary functionzT;bool: f 
T arg2; 

public: 
explicit less than(const Ig x) : arg2(x) ( ) 
bool operatorO(const Ik x) const f return xZarg2; ) 


J; 
Ezek után már leírhatjuk a következőt: 


void f(listzint:£ c) 
( 


listsint:::const. iterator p - find if(c.beginO,c.endO,less thansintx(7)9; 
M az 
) 


A less than(7) forma helyett a less thancint:(7) alakot kell használnunk, mert az Cint: 
sablonparaméter nem vezethető le a konstruktor paraméterének (7) típusából (413.3.1. 


A less than predikátum általában igen hasznos. A fenti művelet viszont úgy jött létre, hogy 
rögzítettük, lekötöttük (bind) a less függvény második paraméterét. Az ilyen szerkezet, mely- 
ben tehát egy paramétert rögzítünk, minden helyzetben ugyanúgy megvalósítható, és annyi- 
ra általános és hasznos, hogy a standard könyvtár egy külön osztályt kínál erre a célra: 


template cclass BinOp: 
class binder2nd : public unary functionZBinOp::first argument type, BinOp::result type: ( 
brotected: 
BinOp op; 
typename BinOp::second argument type arg2; 
bublic: 
binder2nd(const BinOp£ x, const typename BinOp::second argument typeg v) 
: op(x), arg20) ( ) 
result tybe operatorO(const argument typek x) const ( return op(x, arg29; ) 


); 
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template class BinOp, class T- binder2ZndScBinOp: bind2nd(const BinOpk op, const Ik v) 


( 
return binderZndZBinOp:(op,v); 


J 


A bind2ndO függvényobjektumot használhatjuk például arra, hogy meghatározzuk a ,ki- 
sebb, mint 7" egyparamétetű feltételt a less függvény és a 7érték felhasználásával: 


void f(listzint2£ c) 


( 
listzint:::const iterator p - find. ifc.beginO,c.endO, bind2nddlesszint:O, 799; 
1... 


j 


Elég olvasható ez a megoldás? Elég hatékony? Egy átlagos C--t-változat megvalósításával 
összehasonlítva bizony hatékonyabb, mint az eredeti, melyben a §18.4. pont less than 70 
függvényét használtuk — akár időigény, akár tárhasználat szempontjából! Az összehasonlí- 
tás ráadásul könnyen fordítható helyben kifejtett függvényként. 


A jelölés logikus, de megszokásához kell egy kis idő, ezért érdemes konkrét névvel meg- 
adni a kötött paraméterű műveletet is: 


template cclass T- struct less than : public binder2ndz lesszT- 5 ( 
explicit less than(const Ig x) : binder2nddesszT:0,x) ( ) 
ts 


a 


void fddisizintek c) 
( 


listsint:::const iterator p - find if(c.beginO,c.endO, less thansint:(7)9; 
Ms 


J 


Fontos, hogy a less than eljárást a less művelettel határozzuk meg, és nem közvetlenül a c 
operátorral, mert így a less than használni tudja a less bármely elképzelhető specializációját 


(§13.5, §19.2.2. 


A bind2ndO és a binder2nd mellett a Cfunctional: fejállományban megtalálhatjuk 
a bind1st0 és binder1st osztályt is, melyekkel egy kétparaméterű függvény első paraméte- 
rét rögzíthetjük. 


Egy paraméter lekötése, amit a bind1s5t0 és a bind2ndO nyújt, nagyon hasonlít ahhoz az 
általános szolgáltatáshoz, amelyet Currying-nek neveznek. 
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18.4.4.2. Tagfüggvény-átalakítók 


A legtöbb algoritmus felhasznál valamilyen szabványos vagy programozó által megadott 
műveletet. Természetesen gyakran tagfüggvényt szeretnénk meghívni. Például (43.8.59: 


void draw all(listcSshape":k c) 


for. each(c.beginO,c.endO,£k Shape::draw);  // hoppá! hiba 


A problémát az jelenti, hogy egy mf0 tagfüggvény meghívásához az objektumot is meg kell 
adnunk: p-2mfO. Az olyan algoritmusok azonban, mint a for. eachO, a paraméterként ka- 
pott függvényeket az egyszerű függvényhívó utasítással hajtják végre: /0. Ezért szükségünk 
van egy olyan következetes és hatékony módszerre, amivel létrehozhatunk valamit, ami ké- 
pes rávenni az algoritmusokat, hogy tagfüggvényeket hívjanak meg. Egy lehetséges megol- 
dás az lenne, hogy minden algoritmusnak két példányát hozzuk létre: az egyik a tagfügg- 
vényekkel lenne használható, a másik az egyszerű függvényekkel. A helyzet még ennél is 
rosszabb, mert olyan változatokra is szükségünk lenne, amelyek objektumok tárolóin mű- 
ködnének (nem objektumokra hivatkozó mutatókon). Ugyanúgy, mint a lekötők (418.4.4.1) 
esetében, a megoldást itt is egy új osztály és egy függvény megírása jelenti. Először vizsgál- 
juk meg azt az általános esetet, amikor egy tagfüggvényt paraméterek nélkül szeretnénk 
meghívni egy mutatókat tartalmazó tároló minden elemére: 


templatexclass R, class T- class mem fun t : public unary functionzT" R: ( 


R(T:?pmpO; 


public: 
explicit mem fun KR (T::tp)0) :pmhp) 8 
R operatorO( I" p) const f return (p-2"pmfdO; ; // meghívás mutatón keresztül 
J; 
templatexclass R, class T:x mem fun IZR,T: mem fun(R (T::?DPO) 
( 
return mem fun IZRTA(D); 
J 


Ez megoldja a példában szereplő Shape::drawO hívást: 


void draw all(listcShapet:£ lsp) // paraméter nélküli tag meghívása objektumra 
// hivatkozó mutatón keresztül 


for. each(isp.beginO,lsp.endO,mem fun(kShape::draw)); // minden alakzat 
// kirajzolása 
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Ezenkívül szükségünk van egy olyan osztályra és mem funO függvényre is, amelyek a pa- 
raméteres tagfüggvények kezelésére képesek. Olyan változatok is kellenek, melyekkel köz- 
vetlenül objektumokat használhatunk, nem pedig objektumokra hivatkozó mutatókat. Ezek 
neve mem fun refO. Végül szükség van a const tagfüggvényeket kezelő változatokra is: 


templatexclass R, class Tz mem fun I£R,T: mem fun(R (TO; 
// és az egyparaméterű tagokra, a const tagokra, és az egyparaméterű const tagokra 
// vonatkozó változatok (lásd a 618.4.4 táblázatot) 


templatexcilass R, class T: mem fun ref IZR,T- mem fun ref(R(T:?DO; 
// és az egyparaméterű tagokra, a const tagokra, és az egyparaméterű const tagokra 
// vonatkozó változatok (lásd a 618.4.4 táblázatot) 


A cfunctional: fejállomány tagfüggvény-átalakítóinak felhasználásával a következőket 
írhatjuk: 


void fdistsstring:£ ls) // paraméter nélküli tagfüggvény használata objektumra 
( 
typedef listsstring:::iterator LSI; 
ISI p -— find if(is.beginO,ls.endO mem fun ref(kstring::empty)); //"" keresése 


j 


void rotate all(istcShapet:£ ls, int angle) 
// egybaraméterű tagfüggvény használata objektumra hivatkozó mutatón keresztül 


( 
for. eachcis.beginO,ls.endO, bind2Znd(mem fun(ksShape::rotate), angle); 


j 


A standard könyvtárnak nem kell foglalkoznia azokkal a tagfüggvényekkel, melyek egynél 
több paramétert várnak, mert a standard könyvtárban nincs olyan algoritmus, amely kettő- 
nél több paraméterű függvényt várna operandusként. 


18.4.4.3. Függvényre hivatkozó mutatók átalakítói 


Egy algoritmus nem foglalkozik azzal, hogy a , függvényparaméter" milyen formában adott: 
függvény, függvényre hivatkozó mutató vagy függvényobjektum. Ellenben a lekötők 
(418.4.4.1) számára ez fontos, mert tárolniuk kell egy másolatot a későbbi felhasználáshoz. 
A standard könyvtár két átalakítót kínál a függvényekre hivatkozó mutatók szabványos al- 
goritmusokban való felhasználásához. A definíció és a megvalósítás nagyon hasonlít a tag- 
függvény-átalakítóknál (418.4.4.2) használt megoldásra. Most is két függvényt és két osz- 
tályt használunk: 
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template class A, class R: pointer. to unary functionzA,R: ptr. fun(R CCA); 
template class A, class A2, class R: 


bointer. to binary functionZ4A, A2,R2 ptr. fun(R CICA, A299; 


A függvényre hivatkozó mutatók ezen átalakítói lehetővé teszik, hogy a szokásos függvé- 
nyeket a lekötőkkel együtt használjuk: 


class Record f£/? ... "/ 3; 


bool name key eg(const Recordk, const char?);// összehasonlítás nevek alapján 


bool ssn key eg(const Record£, long); // összehasonlítás számok alapján 
void f(listSRecord:£ Ir) // függvényre hivatkozó mutató használata 
( 


typedef typename listizRecord2::iterator LI; 
LI p - find if(ir.beginO, Ir.endO, bind2nd(ptr. fun(name key eg), John Brown"); 
LI ag - find if(Ir.beginO,lr.endO, bind2nd(ptr. funcssn key eg), 1234567890)9, 
JI só 
J 


A fenti utasítások azokat az elemeket keresik meg az /r listában, melyekben a John Browun, 
illetve az 123456 7890 kulcsérték szerepel. 


18.4.4.4. Tagadók 


A predikátum-tagadók (negater) a lekötőkhöz kapcsolódnak abból a szempontból, hogy 
egy műveletet kapnak paraméterként és ebből egy másik műveletet állítanak elő. A taga- 
dók definíciója és megvalósítása követi a tagfüggvény-átalakítóknál (418.4.4.2) alkalmazott 
formát. Meghatározásuk rendkívül egyszerű, de ezt az egyszerűséget kicsit elhomályosítja 
a hosszú szabványos nevek használata: 


template class Pred: 
class unary negate : public unary functionZgtypename Pred::argument type, bool: f 


Pred op; 
bublic: 
explicit unary negate(const Predk p) : op(p) ( ) 
bool operatorO(const argument typeg x) const f return Jop(x9; ) 


vő 


template class Pred: 
class binary negate : public binary functionZtypename Pred::first argument type, 
tybename Pred::second argument type, bool: f 


696 A standard könyvtár 


typedef first argument type Arg; 
typedef second argument type Arg2; 


Pred op; 
bublic: 
explicit binary negate(const Predk p) : op(p) ( ; 
bool operator (const Arg£ x, const Arg2£k y) const ( return lop(x,yI; ) 


J; 


templatexclass Pred: unary negatezPred: not1(const Predk p); // unáris tagadása 
templatezclass Pred: binary negatezPred: not2(const Predk p); /7 bináris tagadása 


Ezek az osztályok és függvények is a S/functional: fejállományban kaptak helyet. 
A first argument type, second argument type stb. elnevezések a unary function, illetve 
a binary function szabványos bázisosztályokból erednek. 


Ugyanúgy, mint a lekötők, a tagadók is kényelmesen használhatók segédfüggvényeiken 
keresztül. Például a ,nem kisebb, mint" kétparaméterű predikátumot is egyszerűen leírhat- 
juk, és megkereshetjük vele az első két olyan szomszédos elemet, melyek közül az első na- 
gyobb vagy egyenlő, mint a második: 


void Kvectorsint:£ vi, listsint:£ li) // a §18.4.2 példájának javított változata 


( 
1... 
b1 - mismatch(vi.beginO, vi.endO, li.beginO, not2(lesszint20)); 
Bé 


J 


Tehát a p7 kapja meg az első olyan elempárt, melyre a ,nem kisebb, mint" művelet hamis 
értéket ad vissza. 


A predikátumok logikai értékekkel dolgoznak, így a bitenkénti operátoroknak ( I, £, A, -) 
nincs megfelelőjük. 


Természetesen a lekötők, az átalakítók és a tagadók együtt is használhatók: 


extern "C" int stremp(const char", const char"); // a ccstdlib: fejállományból 


void f(listécharto£ ls) // függvényre hivatkozó mutató használata 
( 

typedef typename listéchar":::const iterator LI; 

LI p - find if(ls.beginO,ls.endO, not1(bind2nd(ptr. fun(Cstrcmp), "vicces"))); 


J 
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Ez a kódrészlet az első olyan elemet keresi meg az !/s listában, amely a "vicces" C stílusú ka- 
rakterláncot tartalmazza. A tagadóra azért van szükség, mert a strcmpO függvény akkor ad 
vissza 0 értéket, ha a két karakterlánc egyenlő. 


18.5. Nem módosító algoritmusok sorozatokon 


A sorozatok nem módosító algoritmusai elsősorban arra szolgálnak, hogy a sorozatokban 
anélkül kereshessünk meg bizonyos elemeket, hogy ciklust írnánk. Ezen kívül lehetőséget 
adnak arra, hogy az elemekről megtudjunk minden létező információt. Ezek az algoritmu- 
sok csak konstans bejárókat (§19.2.1) használnak és a for. eachO kivételével nem használ- 
hatók olyan műveletek elvégzésére, melyek a sorozat elemeit megváltoztatnák. 


18.5.1. A for each 


Könyvtárakat azért használunk, hogy ne nekünk kelljen azzal fáradozni, amit valaki más 
már megvalósított. Egy könyvtár függvényeinek, osztályainak, algoritmusainak stb. haszná- 
lata megkönnyíti egy program megtervezését, megírását, tesztelését és dokumentálását is. 
A standard könyvtár használata ezenkívül olvashatóbbá is teszi programunkat olyanok szá- 
mára, akik ismerik a könyvtárat, hiszen nem kell időt tölteniük a , házilag összeeszkábált" 
algoritmusok értelmezésével. 


A standard könyvtár algoritmusainak legfőbb előnye, hogy a programozónak nem kell 
megírnia bizonyos ciklusokat. A ciklusok nehézkesek és könnyen követhetünk el bennük 
hibákat. A for. eachO algoritmus a legegyszerűbb algoritmus, abban az értelemben, hogy 
semmi mást nem csinál, minthogy egy ciklust helyettesít, egy sorozat minden elemére vég- 
rehajtva a paraméterében megadott műveletet: 


templatecciass In, class Ob: Op for. each(in first, In last, Op P) 


( 
while (first !- las) főjfirst4a4); 
return f; 


J 


Milyen függvényeket akarunk ilyen formában meghívni? Ha az elemekről akarunk informá- 
ciókat összegyűjteni, az accumulate0 függvényt (422.6) használhatjuk. Ha meg akarunk ta- 
lálni valamit egy sorozatban, rendelkezésünkre áll a findO és a find ifO algoritmus. Ha bi- 
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zonyos elemeket törölni vagy módosítani szeretnénk, a removeO (§18.6.5), illetve 
a replaceO (§18.6.4) jelent egyszerűbb megoldást. Tehát mielőtt használni kezdjük 
a for. eachO eljárást, gondoljuk végig, nincs-e céljainknak jobban megfelelő algoritmus. 


A for. eachO eredménye az a függvény vagy függvényobjektum, amelyet harmadik para- 
méterként megadtunk. A §18.4 pontban a Sum példa bemutatta, hogy ez a megoldás lehe- 
tővé teszi az eredmények visszaadását a hívónak. 


A for. eachO gyakori felhasználási területe az, hogy egy sorozat elemeiből bizonyos infor- 
mációkat fejtünk ki. Például összegyűjthetünk neveket klubok egy listájából: 


void extraci(const listizClub:g lc, listzPersont2k ofp) 
// hivatalnokok áthelyezése Ic-ből "off-ba 


for. each(Ic.beginO, lc.endO, Extract officers(ofp)); 
? 


E 
A §18.4 és a §18.4.2. pontban szereplő példáknak megfelelően készíthetünk egy függvény- 
osztályt, amely kikeresi a kívánt információt. Ebben az esetben a kigyűjtendő neveket 
a listcPerson?: tartalmazza a Club objektumokon belül, ezért az Extract officers függvény- 
nek ki kell másolnia a hivatalnokokat (officer) a Club objektumok officers listájából a gyűj- 
tő listába: 


class Extract officers f( 
listéPersonto£ ist; 
bublic: 
explicit Extract officers(listzPersont:£ x) : Ist(x) ( ? 


void operator((const Club c) 
( copy(c.officers.beginO, c.officers.endO, back. inserter(ISD); ) 


Jo 


A nevek kiíratását szintén a for. eachO függvénnyel végezhetjük: 
void extract and print(const listcclub:£ lc) 
listzPerson? 5 off; 


extract(Ic,ofp); 
for. each(off.beginO, off.endO, Print name(coun); 
2 


9 4 


A Print name függvény megírását meghagyjuk feladatnak (418.13[4D. 
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A for. eachO algoritmust a nem módosító eljárások közé soroltuk, mert közvetlenül nem 
módosít. Ha azonban egy nem konstans sorozatra hívjuk meg, akkor a harmadik paramé- 
terben megadott művelet módosíthatja a sorozatot. (Nézzük meg például a negate0 függ- 
vény használatát a §11.9 pontban.) 


18.5.2. A find függvénycsalád 


A findO algoritmusok végignéznek egy sorozatot (vagy sorozatpárt), és megkeresnek egy 
konkrét értéket vagy egy olyan elemet, amelyre valamilyen állítás (predikátum) teljesül. 
A findO legegyszerűbb változatai csak ezt a feladatot végzik el: 


templatecxclass In, class T- In finddn first, In last, const Ik val; 


templatexclass In, class Pred: In find if(n first, In last, Pred p); 


A findOŐ és a find ifO egy bejárót ad vissza, amely az első olyan elemre mutat, amely a ke- 
resés feltételének megfelel. Valójában a findO felfogható a find ifO egy olyan változatának 
is, ahol a vizsgált predikátum az -——. Miért nem lett mindkét függvény neve findO? Azért, 
mert függvény-túlterheléssel nem mindig tudunk különbséget tenni két azonos paraméter- 
számú sablon függvény között: 


bool pred(Gint9; 


void KvectorsboolCPGny:k v1, vectorcint:£ v2) 


( 
find(1.beginO,v1.endO,pred); // pred!" keresése 
Jfind if(v2.beginO, v2.endO,pred); — // azon int keresése, amelyre predO igazat ad vissza 


J 


Ha a findO és a find ifO függvénynek ugyanaz lenne a neve, akkor igen meglepő többér- 
telműséggel találkoztunk volna. Általában az. ifutótag azt jelzi, hogy az algoritmus egy pre- 
dikátumot vár paraméterként. 


A find first ofO algoritmus egy sorozat első olyan elemét keresi meg, amely megtalálható 
a második sorozatban is: 


templatecciass For, class For22 
For find first o((TFor first, For last, For2 first2, For2 last29; 


templatexclass For, class For2, class BinPred: 
For find first of(For first, For last, For2 first2, For2 last2, BinPred pJ; 
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Például: 


intx[]-€ 134); 
intg[]-( 0,23,4.53; 


void JO 
t 
int" p - find first of(x,x3,y,y45); Sp 7 £x[1] 
int g - find first of(pt1,xt3,y,y459; /ag7 kx[2] 
j 


A p mutató az x/1/ elemre fog mutatni, mert a 3 az első olyan eleme az x-nek, amely meg- 
található az y-ban. Hasonlóan a gaz x/2/-re fog mutatni. 


Az adjacent findO algoritmus két egymás utáni, egyező elemet keres: 


templatezcilass For: For adjacent find(For first, For last); 


templatexclass For, class BinPred: For adjacent find(For first, For last, BinPred p); 


A visszatérési érték egy bejáró, amely az első megfelelő elemre mutat: 


void f((vectorsstring:£ text) 


( 


vectorsstring?2::iterator pb - adjacent find(text.beginO,text.endO); 
if (p/-text.endO k.k "p--laz) (  // Már megint kétszer szerepel az "az"! 
text.erase(p); 


Jaa 


18.5.3. A count() 


A count0 és a count ifO függvény egy érték előfordulásainak számát adja meg egy 
sorozatban: 


templatexclass In, class T- 
tybename iterator. traitsZIn:::difference type countdn first, In last, const Ik val); 


templatecciass In, class Pred: 
typename iterator. traitsZIn:::difference type count if(In first, In last, Pred p); 


18. Algoritmusok és függvényobjektumok 701 


A countO visszatérési értéke nagyon érdekes. Képzeljük el, hogy a countO-ot az alábbi 
egyszerű függvénnyel valósítjuk meg: 


templatecxcliass In, class T- int countdn first, In last, const Tk val 


( 
int res - 0; 
while (first !- last) if Cfirsta4 -- vaD) 44res; 
return res; 


J 


A gond az, hogy egy int lehet, hogy nem felel meg visszatérési értéknek. Egy olyan számí- 
tógépen, ahol az inttípus elég kicsi, elképzelhető, hogy túl sok elem van a sorozatban, így 
a countO0 azt nem tudja egy int-be helyezni. Egy nagyteljesítményű programban, egyedi 
rendszeren viszont érdemesebb a számláló által visszaadott értéket egy s/Aort-ban tárolni. 


Abban biztosak lehetünk, hogy egy sorozat elemeinek száma nem nagyobb, mint a két 
bejárója közötti legnagyobb különbség (419.2.19. Ezért az első gondolatunk a probléma 
megoldására az lehet, hogy a visszatérési érték típusát a következőképpen határozzuk meg: 


typename In::difference type 


Egy szabványos algoritmusnak azonban a beépített tömbökre ugyanúgy kell működnie, 
mint a szabványos tárolókra: 


void K(const char? p, int size) 


( 


int n - count(b,btsize, e); // az "e! betű előfordulásainak megszámlálása 


J 


Sajnos az int"::difference type kifejezés a C44-ban nem értelmezhető. Ez a probléma az 
iterator. traits típus (§19.2.2) részleges specializációjával oldható meg. 


18.5.4. Egyenlőség és eltérés 


Az egualÓ és a mismatchO tüggvény két sorozatot hasonlít össze: 


templatecxcliass In, class In22 bool egual(n first, In last, In2 first29; 


templatecxciass In, class In2, class BinPred: 
bool egualdn first, In last, In2 first2, BinPred p); 
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templatecciass In, class In22 pairsin, In22 mismatch(in first, In last, In2 first29; 


templatecciass In, class In2, class BinPred: 
bairzIn, In22 mismatch(in first, In last, In2 first2, BinPred p); 


Az egualó algoritmus egyszerűen azt mondja meg, hogy a két sorozat minden két megfe- 
lelő eleme megegyezik-e, míg a mismatchO az első olyan elempárt keresi, melyek nem 
egyenlőek, és ezekre mutató bejárókat ad vissza. A második sorozat végét nem kell meg- 
adnunk (tehát nincs last2), mert a rendszer azt feltételezi, hogy az legalább olyan hosszú, 
mint az első sorozat és a last2 értéket a first2--(last-first) kifejezéssel számítja ki. Ezt a mód- 
szert gyakran láthatjuk a standard könyvtárban, amikor két sorozat összetartozó elemei kö- 
zött végzünk valamilyen műveletet. 


A §18.5.1 pontban már említettük, hogy ezek az algoritmusok sokkal hasznosabbak, mint 
azt első ránézésre gondolnánk, mert a programozó határozhatja meg azt a predikátumot, 
melyet az elemek egyenértékűségének eldöntéséhez akar használni. 


A sorozatoknak nem is kell ugyanolyan típusúaknak lenniük: 


void fdistsinteg li, vectorzdoublezk vd) 


( 
bool b - egual(li.beginŐ, li.endO,vd.begin); 


j 


Az egyetlen kikötés, hogy a predikátum paramétereiként használhassuk az elemeket. 


A mismatchO két változata csak a predikátumok használatában különbözik. Valójában 
megvalósíthatjuk őket egyetlen függvénnyel is, amelynek van alapértelmezett sablonpara- 
métere: 


templatecciass In, class In2, class BinPred: 
bairsIln, In22 mismatch(in first, In last, In2 first2, 
BinPred p - egual tozln::value typexO) // §18.4.2.1 


( 
while (first !- last k.k pC"first, "first2)) ( 
HA ÜTSt; 
4-first2; 
j 


return paircin, In22(first first29; 


J 
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A két külön függvény megadása és az egyetlen, alapértelmezett paraméterrel meghatározott 
függvény között akkor láthatjuk a különbséget, ha mutatókat adunk át a függvényeknek. En- 
nek ellenére, ha úgy gondolunk a szabványos algoritmusok különböző változataira, mint 
egy alapértelmezett predikátummal rendelkező függvényre, akkor körülbelül feleannyi sab- 
lon függvényre kell emlékeznünk. 


18.5.5. Keresés 


A searchO), a search nO és a find endŐ algoritmus egy részsorozatot keres egy másik 
sorozatban: 


templatecxciass For, class For22 
For search(For first, For last, For2 first2, For2 last29; 


templatexclass For, class For2, class BinPred: 
For search(Tor first, For last, For2 first2, For2 last2, BinPred p); 


templatecciass For, class For22 
For find end(Tror first, For last, For2 first2, For2 last29; 


templatexclass For, class For2, class BinPred: 
For find end(Tror first, For last, For2 first2, For2 last2, BinPred p); 


templatexcliass For, class Size, class T- 
For search n(rFor first, For last, Size n, const Ik val; 


, 


For search n(For first, For last, Size n, const Tk val, BinPred p); 


templatexclass For, class Size, class T, class BinPred: 


A searchO függvény a másodikként megadott sorozatot keresi az elsőben. Ha megtalálha- 
tó ez a részsorozat, egy bejárót kapunk eredményül, amely az első illeszkedő elemet jelöli 
ki az első sorozatban. Ha a keresés sikertelen, akkor a sorozat végét (/asD kapjuk ered- 
ményképpen. Tehát a visszatérési érték mindig a (/irst, last] tartományban van: 


string guoteC"Minek vesztegessük az időt tanulásra, mikor a tudatlanság azonnali?"); 


bool in guotecconst string 5) 

f 
typedef string::const iterator I; 
Ip - search(guote.beginO), guote.endO,s.beginO,s.endO); // s keresése az idézetben (guote) 
return p/!-guote.endO; 


J 
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void gO 


bool b1 - in guote(" tanulásra"); // b1 - true 


bool b2 - in guote( "tanításra"; // b2 - false 


J 


Tehát a searchO művelettel egy részsorozatot kereshetünk mindenféle sorozatra általáno- 
sítva. Ebből már érezhetjük, hogy a searchO egy nagyon hasznos algoritmus. 


A find endŐ is a másodikként megadott sorozatot keresi részsorozatként az elsőben. Ha si- 
keres a keresés, a find end0O az illeszkedő rész utolsó elemére mutató bejárót adja vissza. 
Mondhatjuk azt is, hogy a find end0O visszafelé végzi ugyanazt a keresést, mint a searchO. 
Tehát nem a részsorozat első előfordulását kapjuk meg, hanem az utolsót. A search n0 el- 
járás egy olyan részsorozatot keres, amely legalább n hosszon a value paraméterben meg- 
adott értéket tartalmazza. A visszatérési érték egy olyan bejáró, amely az n darab illeszke- 
dés első elemére mutat a sorozatban. 


18.6. Módosító algoritmusok sorozatokra 


Ha meg akarunk változtatni egy sorozatot, akkor megtehetjük, hogy egyesével végignézzük 
az elemeket és közben módosítjuk a megfelelő értékeket. De ha lehetőség van rá, akkor ezt 
a programozási stílust érdemes elkerülnünk. Helyette egyszerűbb és rendszerezettebb meg- 
oldás áll a rendelkezésünkre: használjuk a szabványos algoritmusokat a sorozatok bejárá- 
sára és a módosító műveletek elvégzésére. A nem módosító algoritmusok (418.5) ugyanígy 
mennek végig az elemeken, de csak kiolvassák az információkat. A módosító algoritmusok 
segítségével a leggyakoribb frissítési feladatokat végezhetjük el. Ezek egy része az eredeti 
sorozatot módosítja, míg mások új sorozatot hoznak létre az általunk megadott sorozat 
alapján. 


A szabványos algoritmusok a bejárók segítségével férnek hozzá az adatszerkezetekhez. Eb- 
ből következik, hogy egy új elem beszúrása egy tárolóba vagy egy elem törlése nem egy- 
szerű feladat. Például, ha csak egy bejáró áll rendelkezésünkre, hogyan találhatjuk meg azt 
a tárolót, amelyből a kijelölt elemet törölni kell? Hacsak nem használunk egyedi bejárókat 
(például beszúrókat, inserter, §3.8, §19.2.4), a bejárókon keresztül végzett műveletek nem 
változtathatják meg a tároló méretét. Az elemek beszúrása és törlése helyett az algoritmu- 
sok csak az elemek értékét változtatják meg, illetve felcserélnek vagy másolnak elemeket. 
Még a removeO is úgy működik, hogy csak felülírja a törölni kívánt elemeket (418.6.5). 
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Az alapvető módosító algoritmusok általában egy módosított másolatot hoznak létre a meg- 
adott sorozatból. Azok az algoritmusok, melyek sorozatmódosítóknak tűnnek, valójában 
csak a másolók módosított változatai. 


18.6.1. Másolás 


A másolás a legegyszerűbb módszer arra, hogy egy sorozatból egy másikat állítsunk elő. 
Az alapvető másoló műveletek rendkívül egyszerűek: 


templatecciass In, class Out: Out copydin first, In last, Out res) 


( 
while (first !- last) "res44 — Ffirsta; 
return res; 


J 


templatecciass Bi, class Bi22 Bi2 copy backward(Bi first, Bi last, Bi2 res) 
( 


while (first !- lasb) t-res - §--last; 
return res; 


J 


A másoló algoritmus kimenetének nem kell feltétlenül tárolónak lennie. Bármit használha- 
tunk, amihez kimeneti bejáró (419.2.6) megadható: 


void f(listzClub:£ lc, ostream£ 05) 
í 


copy(Ic.beginO, lc.endO, ostream iteratorzClub:(o5)J; 


J 


Egy sorozat beolvasásához meg kell adnunk, hogy hol kezdődik és hol ér véget. Az íráshoz 
csak az az egy bejáró kell, amelyik megmondja, hová írjunk. Arra azonban ilyenkor is fi- 
gyelnünk kell, hogy ne írjunk a fogadó tároló határain túlra. A probléma egyik lehetséges 
megoldása a beszúró (inserter) bejárók (419.2.4) használata, mellyel a fogadó adatszerkeze- 


tet bővíthetjük, ha arra szükség van: 


void Kvectorcchar:£ vs) 


( 


vectorcchar7: u; 


copy(vs.beginO,vs.endO,v.beginO; // túlírhat v végén 
copy(vs.beginO,vs.endO, back inserter(v)); // elemek hozzáadása us-ből v végéhez 


j 
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A bemeneti és a kimeneti sorozat átfedhetik egymást. Ha a sorozatok között nincs átfedés 
vagy a kimeneti sorozat vége a bemeneti sorozat belsejében van, akkor a copyO függvényt 
használjuk. A copy backwardO utasításra akkor van szükség, ha a kimeneti sorozat eleje 
van a bemeneti sorozatban. Ez a függvény ilyen helyzetben addig nem írja felül az eleme- 
ket, amíg azokról másolat nem készült (lásd még §18.13[13D. 


Természetesen ahhoz, hogy valamit visszafelé másoljunk le, egy kétirányú bejáróra 
(419.2.1) van szükségünk, mind a bemeneti, mind a kimeneti sorozatban: 


void fwectorcchar:£ vc) 


( 


vectorcchar? v(vc.sizeO); 


copy. backward(vc.beginO, vc.endO,ostream, iteratorkchar:(couD)); // hiba 
copy backward(vc.beginO,vc.endO,v.endO); // rendben 
copy(v.beginŐ,v.endO,ostream iteratoráchar:(couD); // rendben 


Gyakran olyan elemeket szeretnénk másolni, amelyek egy bizonyos feltételt teljesítenek. 
Sajnos a copy ifO függvény valahogy kimaradt a standard könyvtár által nyújtott algoritmu- 
sok sorából (mea culpa). De ha szükségünk van rá, pillanatok alatt megírhatjuk: 


templatexclass In, class Out, class Pred: Out copy ifdn first, In last, Out res, Pred p) 


( 
while (first !- lasb) f 
if PCfirsD) ?rest4 7 "first; 
4 ÜTSt; 
J 


return res; 


j 


Ezután ha az n értéknél nagyobb elemeket akarjuk megjeleníteni, a következő eljárást 
használhatjuk: 


void fddisizintegld, int n, ostream£ os) 


copy if(ld.beginO,ld.endOŐ,ostream. iteratorsint:(os), bind2Znd(greatersint20,n)); 


j 


(ásd még a remove copy ifÖleírását is a §18.6.5 pontban.) 
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18.6.2. Transzformációk 


Egy kicsit félrevezető a neve, ugyanis a transformO nem feltétlenül változtatja meg a beme- 
netét. Ehelyett egy olyan kimenetet állít elő, amely a bemeneten végzett felhasználói műve- 
let eredménye: 


templatecciass In, class Out, class OD: 
Out transform(in first, In last, Out res, Op op) 


( 
while (first !1- last) "res44 — opCfirsta4 ); 
return res; 


J 


templatecxclass In, class In2, class Out, class BinOp: 
Out transform(in first, In last, In2 first2, Out res, BinOp op) 


( 
while (first !- last) "res44 - opCfirsta-4, Efirst244 ); 
return res; 


J 


A transformO függvény első változata, amely csak egy sorozatot olvas be, nagyon hasonlít 
az egyszerű másolásra. A különbség mindössze annyi, hogy a közvetlen kiírás helyett előbb 
egy transzformációt (átalakítás0) is elvégez az elemen. Így a copyO eljárást a transformO 
függvénnyel is meghatározhattuk volna, úgy, hogy az elemmódosító művelet egyszerűen 
csak visszaadja a paraméterét: 


templatexciass T- T identity(const Ik x) ( return x; ) 


templatecciass In, class Out: Out copydn first, In last, Out res) 


( 


return transform(first, last, res, identity); 


J 


Az identity explicit minősítése ahhoz szükséges, hogy a függvénysablonból konkrét függ- 
vényt kapjunk, az iterator. traits sablont (419.2.2) pedig azért használtuk, hogy az In elem- 
típusához jussunk. 


A transformO függvényt tekinthetjük a for. eachO egy változatának is, amely közvetlenül 
állítja elő kimenetét. Például klubok listájából a transformO segítségével készíthetünk egy 
olyan listát, amely csak a klubok neveit tárolja: 


string nameof(const Club c) // név kinyerése 


( 


return c.name; 


J 
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void fistzClub:£ lc) 
( 


transform(ílc.beginO, lc.endO,ostream. iteratorsstring:(cout) nameoj); 


J/ 


A transformO függvény elnevezésének egyik oka az, hogy az eredményt gyakran visszaír- 
juk oda, ahonnan a paramétert kaptuk. Például ha olyan objektumokat akarunk törölni, me- 
lyekre mutatók hivatkoznak, a következő eljárást használhatjuk: 


struct Delete ptrf — //függvényobjektum használata helyben kifejtéshez (inline fordításhoz) 


templatexclass T- T" operatorO (1T" p) ( delete p; return O; ) 
2. 


Jo 
void purge(deguecShape?:£ s) 


( 


transform(s.beginO,s.endO,s.beginO, Delete ptr); 


j 


A transformO algoritmus eredménye mindig egy kimeneti sorozat. A fenti példában az 
eredményt az eredeti bemeneti sorozatba irányítottuk vissza, így a Delete ptrO(p) jelenté- 
se p-Delete ptrO(p) lesz. Ez indokolja a 0 visszatérési értéket a Delete bptr::oberatorOO 
függvényben. 

A transformO algoritmus másik változata két bemeneti sorozattal dolgozik. Ez lehetővé te- 
szi, hogy két sorozat adatait használjuk fel az új sorozat létrehozásához. Egy animációs 
programban például szükség lehet egy olyan eljárásra, amely alakzatok sorozatának helyét 
frissíti valamilyen átalakítással: 


Shape? move shape(Shape" s, Point p) / "s 4-p 
( 

s-2move to(s-2center01p); 

return s; 


j 


void update positions(listcShape":k ls, vectoréPoint:£ oper) 


( 


// művelet végrehajtása a megfelelő objektumon 


transform(ls.beginO,ls.endO, oper.beginO, ls.begin , move shape); 


J 


Valójában nem lenne szükségünk arra, hogy a move shapeO függvénynek visszatérési ér- 
téke legyen, de a transformO ragaszkodik a művelet eredményének felhasználásához, így 
a move shapeO visszaadja az első operandusát, amelyet visszaírhatunk az eredeti helyére. 
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Bizonyos helyzetekben ezt a problémát nem oldhatjuk meg így. Ha a műveletet például 
nem mi írtuk vagy nem akarjuk megváltoztatni, akkor nem áll rendelkezésünkre a megfe- 
lelő visszatérési érték. Máskor a bemeneti sorozat const. Ezekben az esetekben egy kétso- 
rozatos for. eachO függvényt készíthetünk, amely a kétsorozatos transformO párjának 
tekinthető: 


templatecxclass In, class In2, class BinOp: 
BinOp for. each(in first, In last, In2 first2, BinOp op) 
( 


while (first !- las9) opCfirsta-4, "first24a ); 
return op; 


J 


void update positions(listcShapet:k ls, vectorcPoint:£ oper) 


( 
for. eachcis.beginO,ls.endO, oper.begin move shape); 


J 


Esetenként olyan kimeneti bejáró is hasznos lehet, amely valójában semmit sem ír 


(419.6I2D. 


A standard könyvtár nem tartalmaz olyan algoritmusokat, melyek három vagy négy soro- 
zatból olvasnak, bár ezek is könnyen elkészíthetők. Helyettük használhatjuk többször egy- 
más után a transformO függvényt. 


18.6.3. Ismétlődő elemek törlése 


Amikor információkat gyűjtünk, könnyen előfordulhatnak ismétlődések. A unigueO és 
a unigue copyO algoritmusokkal az egymás után előforduló azonos értékeket távolíthatjuk el: 


templatexclass For: For unigue(ror first, For las0); 
templatexclass For, class BinPred: For unigue(Tror first, For last, BinPred p); 


templatecciass In, class Out: Out unigue copy(in first, In last, Out res); 
templatecciass In, class Out, class BinPred: 
Out unigue copy(n first, In last, Out res, BinPred p); 


A unigueO megszünteti a sorozatban egymás után előforduló értékismétlődéseket, 
a unigue copyO pedig egy másolatot készít az ismétlődések elhagyásával: 
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void f(listsstring:£ ls, vectorsstring:£ vs) 


( 
Is.sortO; // listarendezés (§17.2.2. 1) 


unigue copy(is.beginO,ls.endO, back inserter(vs)); 


j 


Ezzel a programrészlettel az /s listát átmásolhatjuk a vs vektorba és menet közben kiszűrhet- 
jük az ismétlődéseket. A sort0 utasításra azért van szükség, hogy az egyenértékű elemek 
egymás mellé kerüljenek. 


A többi szabványos algoritmushoz hasonlóan a unigueO is bejárókkal dolgozik. Azt nem 
lehet megállapítani, hogy ezek a bejárók milyen típusú tárolóra mutatnak, így a tárolót nem 
változtathatjuk meg, csak az annak elemeiben tárolt értékeket módosíthatjuk. Ebből követ- 
kezik, hogy a unigueO nem törli az ismétlődéseket a sorozatból, ahogy azt naívan remél- 
nénk. Ehelyett az egyedi elemeket a sorozat elejére helyezi és visszaad egy bejárót, amely 
az egyedi elemek részsorozatának végére mutat: 


template class For: For unigue(rFor first, For las) 


( 
first - adjacent find(first, las); // §18.5.2 
return unigue copy(first, last, firsD; 
j 
A részsorozat utáni elemek változatlanok maradnak, tehát egy vektor esetében ez a megol- 


dás nem szünteti meg az ismétlődéseket: 


void fvectorsstring:őt vs) // vigyázat: rossz kód! 
( 
sort(vs.begin, vs.endO 9; // vektorrendezés 
unigue(vs.beginO), vs.endO ); // ismétlődések eltávolítása (nem működik) 


j 
Sőt azzal, hogy a unigueO a sorozat végén álló elemeket előre helyezi az értékismétlődé- 
sek megszüntetéséhez, akár új ismétlődések is keletkezhetnek: 


int mainŐ 


( 


char ul ] - "abbcccde"; 


char? p - unigue(vw,vistrlen(v); 
cout ££ v 22! ! 2£ p-v cz Mm; 


j 
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Az eredmény a következő lesz: 


abcdecde 5 


Tehát a p a második c betűre mutat. 


Azoknak az algoritmusoknak, melyeknek törölnie kellene elemeket (de ezt nem tudják 
megtenni), általában két változata van. Az egyik a unigeO módszerével átrendezi az eleme- 
ket, a másik egy új sorozatot hoz létre a unigue cobyO működéséhez hasonlóan. A copy 
utótag ezen két változat megkülönböztetésére szolgál. 


Ahhoz hogy az ismétlődéseket ténylegesen kiszűrjük egy tárolóból, még egy további utasí- 
tásra van szükség: 


templatexclass C: void eliminate duplicates(Ck c) 


( 
sort(c.beginO, c.endO ); // rendezés 
typename C:iterator p - unigue(c.begin ,c.endO); —— // tömörítés 
c.erase(p,c.endO); // zsugorítás 
j 


Sajnos az eliminate duplicatesO függvény a beépített tömbökhöz nem használható, míg 
a unigueO azoknál is működik. 


A unigue copyO használatára a §3.8.3. pontban mutattunk példát. 


18.6.3.1. Rendezési szempont 


Az összes ismétlődés megszüntetéséhez a bemeneti sorozatot rendeznünk kell (418.7.1. 
Alapértelmezés szerint a unigueO és a unigue copyO is az --— operátort használja az egyen- 
lőségvizsgálathoz, de lehetővé teszik, hogy a programozó más műveletet adjon meg. 
A §18.5.1 pontban szereplő programrészletet például átalakíthatjuk úgy, hogy kiszűrje az 
ismétlődő neveket. Miután a klubok hivatalnokainak nevét összegyűjtöttük, az o/flistához 
jutottunk, melynek típusa listéPerson": (§18.5.1). Ebből a listából az ismétlődéseket a kö- 
vetkező utasítással törölhetjük: 


eliminate duplicates(ofp); 


Ez a megoldás azonban mutatókat rendez, és csak akkor fog céljainknak megfelelően mű- 
ködni, ha feltételezzük, hogy minden Person objektumra egyetlen mutató hivatkozik. 
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Az egyenértékűség eldöntéséhez általában magukat a Person rekordokat kell megvizsgál- 
nunk. Ehhez a következő programrészletet kell megírnunk: 


bool operator-—(const Personkt x, const Persong y) // "egyenlőség" objektumra 


( 


// x és y összehasonlítása egyenlőségre 


j 


bool operators(const Personkg x, const Persondz y) // "kisebb mint" objektumra 


( 


// x és y összehasonlítása rendezettségre 


J 


bool Person eg(const Person? x, const Person? y) // "egyenlőség" mutatón keresztül 


( 


return ?x -- 8, 


j 


bool Person lt(const Person? x, const Person? y) // "kisebb mint" mutatón keresztül 


( 


return ?x £ ?y; 


j 


void extract and print(const listcclub:£ lc) 


( 
listzPerson?" 5 off; 
extract(Ic,ofp9; 
off.sort(off,Person ID; 
listzClub:::iterator p - unigue(off.beginO, off.endO, Person eg); 
for. each(off.beginO,p,Print name(coun); 


Érdemes mindig gondoskodnunk arról, hogy a rendezéshez használt feltétel ugyanaz le- 
gyen, mint az ismétlődések kiszűrésére szolgáló eljárás. A € és az —— operátorok alapértel- 
mezett jelentése mutatók esetében általában nem felel meg számunkra a mutatott objektu- 
mok összehasonlításához. 


18.6.4. Helyettesítés 


A replace0 algoritmusok végighaladnak a megadott sorozaton, és egyes értékeket újakra 
cserélnek, a mi igényeinknek megfelelően. Ugyanazt a mintát követik, mint a find/find if 
és a unigue/ unigue copy, így összesen négy változatra van szükség. A függvények megva- 
lósítása most is elég egyszerű ahhoz, hogy jól magyarázza szerepüket: 
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templatecciass For, class T- 


void replace(For first, For last, const Tk val, const Ik new val) 


t 
while (first !- lasb) f 
if Cfirst —— val) "first - new val; 
4--first; 
) 
j 


templatexclass For, class Pred, class T- 


void replace if(For first, For last, Pred p, const Ik new val) 
t 


while (first !- lasb) f 
if (PCfirsD) "first - new val; 
tt. first; 
) 
j 


templatecciass In, class Out, class T: 


Out replace copydin first, In last, Out res, const Tk val, const Ik new val) 


f 
while (first !- lasb) f 
krest4 — (first -— vaD ? new val : "first; 
tr first; 
) 


return res; 


J 


templatecciass In, class Out, class Pred, class T- 
Out replace copy if(in first, In last, Out res, Pred p, const Ik new val) 


( 
while (first !- lasb) f 


Xrest4t - pOfirsD ? new val : "first; 
tr first; 


) 


return res; 


j 


gol átírását (Aarhus) a helyes Árhus változatra kell cserélnem: 


void (f(listsstring2£ towns) 


( 
j 


replace(towns.beginO), towns.endO, "Aarhus", "Árhus"); 


Természetesen ehhez egy kibővített karakterkészletre van szükség (4C.3.3) 


Sűrűn előfordul, hogy karakterláncok egy listáján végighaladva szülővárosom szokásos an- 
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18.6.5. Törlés 


A removeg algoritmusok elemeket törölnek egy sorozatból, érték vagy feltétel alapján: 


templatexciass For, class T- For remove(For first, For last, const Ik val); 
templatexclass For, class Pred: For remove if(For first, For last, Pred p); 


templatexclass In, class Out, class T- 
Out remove copydn first, In last, Out res, const Ik val); 


templatexclass In, class Out, class Pred: 
Out remove copy iflin first, In last, Out res, Pred p); 


Tegyük fel például, hogy a Club osztályban szerepel egy cím mező is és feladatunk az, hogy 
összegyűjtsük a koppenhágai klubokat: 


class located in : public unary functionzcCiub, bool: f 
string town; 
bublic: 
located in(const stringét ss) :town(ss) ( ) 
bool operator (const Clubg c) const f return c.town -- town; ) 
7 
void fistzClub:£ 1) 
t 
remove copy ifllc.beginO,lc.endO, 
ostream, iteratorzClub:(cout), not1 (located in("Koöbenhaun"))); 


j 


A remove copy ifO ugyanaz, mint a copy ifO, csak fordított feltétellel. Tehát 
a remove copy ifO akkor helyez egy elemet a kimenetre, ha az nem elégíti ki a feltételt. 


A ,sima" remove(a sorozat elejére gyűjti a nem törlendő elemeket és az így képzett részso- 
rozat végére mutató bejárót ad vissza (lásd még §18.6.3). 
18.6.6. Feltöltés és létrehozás 


A fillő és a generateO algoritmusok segítségével rendszerezetten tölthetünk fel egy soroza- 
tot értékekkel: 


templatecciass For, class T- void fill(For first, For last, const Ik vaD; 
templatexclass Out, class Size, class T- void fill nCOut res, Size n, const Tk val; 
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templatexclass For, class Gen: void generate(For first, For last, Gen 9); 
templatexcilass Out, class Size, class Gen: void generate n(Out res, Size n, Gen g); 


A fill0 függvény megadott értékeket ad a sorozat elemeinek, míg a generate0 algoritmus 
úgy állítja elő az értékeket, hogy mindig meghívja a megadott függvényt. Tehát a /ill0 
a generateO egyedi változata, amikor az értékeket előállító létrehozó, generátor) függvény 
mindig ugyanazt az értéket adja vissza. Az n változatok a sorozat első nz elemének adnak 


értéket. 


A §22.7 pont Randint és Urand véletlenszám-előállítójának felhasználásával például a kö- 
vetkezőt írhatjuk: 


int v1(900)J; 
int v2/900)J; 
vector V3; 


void JO 


( 
Jillrv1,kv1(9007, 999; // v1 minden elemének 99-re állítása 
generate(v2,£k v21900/, RandintO0); — /7 véletlen értékekre állítás (§22.7) 


// 200 véletlen egész küldése a kimenetre a (0O..99/] tartományból 
generate n(ostream, iteratorsint-(cout), 200, Urand(100)); 


Jill n(back inserter(v3), 20, 999; // 20 darab 99 értékű elem hozzáadása v3-hoz 


A generatel és a fill0 nem kezdeti, hanem egyszerű értékadást végez. Ha nyers tárolóterü- 
letet akarunk felhasználni (például egy memóriaszeletet meghatározott típusú és állapotú 
objektummá szeretnénk alakítani), használhatjuk például az uninitialized fill0 függvényt, 
a Cmemory? fejállományból (§19.4.4). Az calgorithm: állomány algoritmusai ilyen célokra 
nem felelnek meg. 


18.6.7. Megfordítás és elforgatás 


Időnként szükségünk van rá, hogy egy sorozat elemeit átrendezzük: 


templatexclass Bi: void reverse(Bi first, Bi lasD); 
templatecciass Bi, class Out: Out reverse copy(Bi first, Bi last, Out res); 


templatexcilass For? void rotate(For first, For middle, For last); 
templatecciass For, class Out: Out rotate copy(For first, For middle, For last, Out res); 
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templatezclass Ran: void random shujffleCRan first, Ran last); 
templatesclass Ran, class Gen: void random shujffle(Ran first, Ran last, Gendt 2); 


A reverseO algoritmus megfordítja az elemek sorrendjét, tehát az első elem lesz az utolsó 
stb. A reverse copyO szokás szerint egy másolatban állítja erő bemeneti sorozatának meg- 
fordítását. 


A rotateO algoritmus a (first, last/ sorozatot körként kezeli, és addig forgatja az elemeket, 
míg a korábbi middle elem a sorozat elejére nem kerül. Tehát az az elem, amely eddig 
a first4i pozíción volt, a művelet után a /irst- (it (last-middle)) 9o(last-first) helyre kerül. 
A 96 (modulus) operátor teszi a forgatást ciklikussá az egyszerű balraléptetés helyett: 


void JO 

( 
string ul ] - f "Béka", "és", "Barack" ); 
reverse(v,v43); // Barack és Béka 
rotate(v,vt1,v43); // és Béka Barack 


J 


A rotate copyO egy másolatban állítja elő bemeneti sorozatának elforgatott változatát. 


Alapértelmezés szerint a random shuffleO0 megkeveri a paraméterében megadott sorozatot 


egy egyenletes eloszlású véletlenszámokat előállító eljárás segítségével. Tehát az elemek 
egyik permutációnak ugyanakkora esélye van. Ha más eloszlást szeretnénk elérni vagy egy- 
szerűen csak jobb véletlenszám-előállítónk van, akkor azt megadhatjuk a random shujffleO 
függvénynek. A §22.7. pont Urand eljárásával például a következőképpen keverhetjük meg 
egy kártyapakli lapjait: 


void (ideguezCard:£k dc, My randá£ r) 
( 
random, shujffle(dc.beginO,dc.endO,r); 
Jesz 
j 
Az elemek áthelyezését a rotate0 és más függvények a swapO függvény (§18.6.8) segítsé- 
gével hajtják végre. 
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18.6.8. Elemek felcserélése 


Ha bármi érdekeset szeretnénk végrehajtani egy tároló elemeivel, akkor mindig át kell he- 
lyeznünk azokat. Ezt az áthelyezést legjobban - tehát a legegyszerűbben és a leghatéko- 
nyabban - a swapO függvénnyel fejezhetjük ki: 


templatexclass T: void swap(Ik a, Ik b) 


t 
T tmp — a; 
a - b; 
b - tmp; 

J 


templatexclass For, class For2? void iter. swap(For x, For2 y); 


templatexclass For, class For2: For2 swap ranges(For first, For last, For2 first2) 


( 
while (first !- last) iter. swap(firsta4, first24-a); 
return first2; 


J 


Ahhoz, hogy felcseréljünk elemeket, egy ideiglenes tárolóra van szükségünk. Egyes esetek- 
ben lehetnek ügyes trükkök, melyekkel ez elkerülhető, de az egyszerűség és érthetőség ér- 
dekében érdemes elkerülni az ilyesmit. A swapO algoritmus rendelkezik egyedi célú válto- 
zatokkal azokhoz a típusokhoz, ahol erre szükség lehet (§416.3.9, §13.5.29. 


Az iter. swapO algoritmus bejárókkal kijelölt elemeket cserél fel, a swap rangesO pedig két 
bemeneti paramétere által meghatározott tartománya elemeit cseréli fel. 


18.7. Rendezett sorozatok 


Miután összegyűjtöttük az adatokat, általában szeretnénk rendezni azokat. Ha rendezett so- 
rozat áll rendelkezésünkre, sokkal több lehetőségünk lesz arra, hogy adatainkat kényelme- 
sen kezeljük. 


Egy sorozat rendezéséhez valahogyan össze kell hasonlítanunk az elemeket. Ehhez egy 
kétparaméterű predikátumot (418.4.2) használhatunk. Az alapértelmezett összehasonlító 
művelet a /ess (418.4.2), amely viszont alapértelmezés szerint a € operátort használja. 
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18.7.1. Rendezés 


A sort rendező algoritmusoknak közvetlen elérésű (véletlen elérésű) bejárókra (419.2.1 
van szükségük. Ebből következik, hogy a vektorok (416.3) és az ahhoz hasonló szerkeze- 
tek esetében működnek a leghatékonyabban: 


templatezclass Ran: void sort(Ran first, Ran lasD; 
templatezclass Ran, class Cmp: void sort(Ran first, Ran last, Cmp cmp); 


templatezclass Ran: void stable sort(Ran first, Ran las1); 
templatexclass Ran, class Cmp: void stable sort(Ran first, Ran last, Cmp cmp); 


A szabványos list (§17.2.2) osztály nem biztosít közvetlen hozzáférésű bejárókat, így azokat 
megfelelő listaműveletekkel (417.2.2.1) kell rendeznünk. 


Az egyszetű sortÓ eljárás elég hatékony — átlagosan N"/og(Ww) — de a legrosszabb esetre vett 
hatékonyság elég rossz: OCGV"N). Szerencsére a , legrosszabb" eset elég ritka. Ha a leg- 
rosszabb esetben is garantált működésre vagy stabil rendezésre van szükségünk, használ- 
juk a stable sortO függvényt. Ennek hatékonysága N"log(N)"log(N), ami N"log(N) értékre 
javul, ha a rendszerben elég memória áll rendelkezésünkre. A stable sortO — a sortO függ- 


vénnyel ellentétben — megtartja az egyenértékűnek minősített elemek sorrendjét. 


Bizonyos helyzetekben a rendezett sorozatnak csak első néhány elemére van szükségünk. 
Ebben az esetben van értelme annak, hogy a sorozatot csak olyan hosszon rendezzük, ami- 
lyenre éppen szükségünk van. Ezt nevezzük részleges (parciális) rendezésnek: 


templatexclass Ran: void partial sort(Ran first, Ran middle, Ran last); 
templatexclass Ran, class Cmp: 
void partial sort(Ran first, Ran middle, Ran last, Cmp cmp); 


templatexclass In, class Ran: 

Ran partial sort copydn first, In last, Ran first2, Ran last29; 
templatecciass In, class Ran, class Cmp: 

Ran partial sort copydn first, In last, Ran first2, Ran last2, Cmp cmp)J; 


A partial sortO algoritmus alapváltozata a /irst és a middle közötti elemeket rendezi el. 
A partial sort copyO algoritmusok egy N elemű sorozatot hoznak létre, ahol Va bemene- 
ti és kimeneti sorozat elemei számának minimuma. Ebből következik, hogy meg kell ad- 
nunk az eredménysorozat elejét és végét is, hiszen ez határozza meg, hány elemet kell el- 
rendezni: 
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class Compare copies sold ( 
bublic: 
int operatorO(const Bookk b1, const Bookk b2) const 
f return b1.copies soldO:b2.copies soldO;) /7 rendezés csökkenő sorrendben 


Vé 


void K(const vectorSBook:£ sales) // a tíz legjobban fogyó könyv megkerése 


( 


vectorSBook: bestsellers(109; 
partial sort copy(sales.beginO, sales.endO, 

bestsellers.beginO), bestsellers.endO, Compare copies soldO); 
copy(bestsellers.beginO) bestsellers.endO, ostream iteratorSBook:(cout, Mm"); 


) 


Mivel a partial sort copyO kimenetének egy véletlen elérésű bejárónak kell lennie, nem 
rendezhetünk egy sorozatot egyenesen a cout adatfolyamra. 


Végül nézzük azokat az algoritmusokat, melyekkel pontosan csak annyi elemet rendezhe- 
tünk el, amennyi az N-edik elem helyének megállapításához szükséges. Ezek azonnal be- 
fejezik működésüket, ha a kívánt elemet megtalálták: 


templatezclass Ran: void nth element(Ran first, Ran nth, Ran last); 
templatexclass Ran, class Cmp: void nth element(Ran first, Ran nth, Ran last, Cmp cmp); 


Ez a függvény különösen hasznos azoknak, akiknek középértékre, százalékarányra stb. van 
szükségük (mérnököknek, szociológusoknak, tanároknak). 


18.7.2. Bináris keresés 


A sorban történő (soros, szekvenciális) keresés, amit a findO is végez, szörnyen rossz ha- 
tásfokú nagy sorozatok esetében, mégis ez a legjobb megoldás, ha sem rendezés, sem ha- 
sítás (17.69) nem áll rendelkezésünkre. Ha azonban rendezett sorozatban keresünk, akkor 
annak megállapítására, hogy egy érték szerepel-e a sorozatban, használhatjuk a bináris ke- 
resést: 


templatexclass For, class T- bool binary search(For first, For last, const Tk val; 


templatecxciass For, class T, class Cmp: 
bool binary search(For first, For last, const Tk value, Cmp cmp); 
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Például: 


void fdisizint£k c) 


( 
if (binary search(c.beginO,c.endO, 79) ( 
HZANES 
) 
VS 


j 


/ Van 7 a c-ben? 


A binary searchO egy logikai értéket ad vissza, jelezvén, hogy az érték szerepel-e a soro- 
zatban. Ugyanúgy, mint a findO esetében, itt is gyakran tudni szeretnénk, hogy az adott ér- 
tékkel rendelkező elem hol található. Egy sorozatban azonban több megfelelő érték is le- 
het, és nekünk általában vagy az elsőre, vagy az összesre van szükségünk. Ezért szerepel- 
nek a standard könyvtárban azok az eljárások, melyekkel az első (/ower. boundO), az utol- 
só (upper. boundO) vagy az összes (egual rangeO) megfelelő (egyenértékű) elemet kivá- 


laszthatjuk: 


templatexciass For, class T- For lower. bound(For first, For last, const Ik vaD; 


templatecxciass For, class T, class Cmp: 


For lower. bound(ror first, For last, const Tk val, Cmp cmp); 


templatexciass For, class T- For upber. bound(For first, For last, const Ik val; 


templatexciass For, class T, class Cmp: 


For upper. bound(Tor first, For last, const Ik val, Cmp cmp); 


templatexclass For, class T- pairsFor, For: egual range(For first, For last, const Ik val; 


templatecxciass For, class T; class Cmp: 


bairsFor, For? egual range(Tor first, For last, const Tk val, Cmp cmp); 


Ezek az algoritmusok a multimap (§17.4.2) műveletei közé tartoznak. A lower. boundO 
függvényt úgy képzelhetjük el, mint a /findO) illetve a find ifŐ gyors változatát rendezett 


sorozatokra: 


void g(vectorsint-k c) 


( 


typedef vectorsint:::iterator VI; 


VI p - find(c.beginO,c.endO, 79; 


VI ag - lower. bound(c.beginO, c.endO, 79; 


vs 


// valószínűleg lassú: O(N); c-t nem kell 
// rendezni 

// valószínűleg gyors: O(log(NI9; c-t 

// rendezni kell 
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Ha a lower. bound(first, last, k) nem találja meg a k értéket, akkor egy olyan bejárót ad 
vissza, amely az első, k-nál nagyobb kulccsal rendelkező elemre mutat, vagy a last bejárót, 
ha nincs £k-nál nagyobb érték. Az upper. boundO és az egual range szintén ezt a hibajel- 
zési módszert használja. Ezekkel az algoritmusokkal meghatározhatjuk, hogy hová kell az 
új elemet beszúrnunk, ha a sorozat rendezettségét nem akarjuk elrontani. 


18.7.3. Összefésülés 


Ha van két rendezett sorozatunk, akkor a mergeO segítségével egy új rendezett sorozatot 
hozhatunk létre belőlük, az inblace merge függvény felhasználásával pedig egy sorozat 
két részét fésülhetjük össze: 


templatecciass In, class In2, class Out: 

Out merge(in first, In last, In2 first2, In2 last2, Out res); 
templatecciass In, class In2, class Out, class Cmp: 

Out merge(in first, In last, In2 first2, In2 last2, Out res, Cmp cmp); 


templatecxclass Bi: void inplace merge(Bi first, Bi middle, Bi las); 
templatecxciass Bi, class Cmp?: void inplace merge(Bi first, Bi middle, Bi last, Cmp cmp); 


Ezek az összefésülő algoritmusok abban térnek el jelentősen a /ist osztály hasonló eljárása- 
itól (417.2.2.19, hogy nem törlik az elemeket a bemeneti sorozatokból. Minden elemről kü- 
lön másolat készül. 


Az egyenértékű elemek sorrendjéről azt mondhatjuk el, hogy az első sorozatban lévő ele- 
mek mindig megelőzik a második sorozat azonos elemeit. 


Az inplace mergeO algoritmus elsősorban akkor hasznos, ha egy sorozatot több szempont 
szerint is rendezni akarunk. Képzeljük el például , halaknak egy vektorát", amely fajok (he- 
ring, tőkehal stb.) szerint rendezett. Ha a halak minden fajon belül súly szerint rendezettek, 
akkor az inplace mergeO segítségével könnyen rendezhetjük az egész vektort a súlyok 
alapján, hiszen csak az egyes fajták részsorozatait kell összefésülnünk (§18.13[20D. 


18.7.4. Felosztás 


Egy sorozat felosztása (partition) azt jelenti, hogy minden olyan elemet, amely kielégít egy 
adott feltételt, a sorozat elejére helyezünk, a feltételt ki nem elégítőket pedig a végére. 
A standard könyvtárban rendelkezésünkre áll a szable partitionO függvény, amely megtart- 
ja azon elemek egymáshoz viszonyított sorrendjét, melyek egyformán megfelelnek vagy 
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egyformán nem felelnek meg a predikátumnak. A könyvtárban szerepel a partitionO eljá- 
rás is, amely ezt a sorrendet nem őrzi meg, de egy kicsit gyorsabban fut le, ha kevesebb me- 
mória áll rendelkezésünkre. 


templatecciass Bi, class Pred: Bi partition(Bi first, Bi last, Pred p9; 
templatecxciass Bi, class Pred: Bi stable partition(Bi first, Bi last, Pred p); 


A felosztást úgy képzelhetjük el, mint egy nagyon egyszerű feltétel szerinti rendezést: 


void f(listzClub:£ 1) 
( 


lisizClub:::iterator p - partition(lc.beginO, lc.endO, located inC"Kobenhaun")); 
oda 


j 
Ez az eljárás úgy rendezi" a listát, hogy a koppenhágai klubok szerepeljenek először. 
A visszatérési érték (esetünkben a D) az első olyan elemet határozza meg, amely nem elé- 
gíti ki a feltételt, illetve ha ilyen nincs, akkor a sorozat végére mutat. 


18.7.5. Halmazműveletek sorozatokon 


A sorozatokat tekinthetjük halmaznak is. Ebből a szempontból viszont illik a sorozatokhoz 
is elkészítenünk az olyan alapvető halmazműveleteket, mint az unió vagy a metszet. Más- 
részt viszont ezek a műveletek rendkívül költségesek, hacsak nem rendezett sorozatokkal 
dolgozunk. Ezért a standard könyvtár halmazkezelő algoritmusai csak rendezett sorozatok- 
kal használhatók. Természetesen nagyon jól működnek a set (§17.4.3) és a multiset(417.4.4) 
tároló esetében is, melyek szintén rendezettek. 


Ha ezeket az algoritmusokat nem rendezett sorozatokra alkalmazzuk, az eredménysoroza- 
tok nem fognak megfelelni a szokásos halmazelméleti szabályoknak. A függvények nem 
változtatják meg bemeneti sorozataikat és a kimeneti sorozat rendezett lesz. 


Az includes algoritmus azt vizsgálja, hogy a második sorozat minden eleme (a (first2, last2/ 
tartományból) megtalálható-e az első sorozat elemei között (a /first, last/ tartományban: 


templatexclass In, class In2: 

bool includes(in first, In last, In2 first2, In2 last29; 
templatexclass In, class In2, class Cmp: 

bool includesídín first, In last, In2 first2, In2 last2, Cmp cmp); 
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A set unionO rendezett sorozatok unióját, a set intersection függvény pedig metszetüket 
állítja elő: 


templatecciass In, class In2, class Out: 

Out set union(1n first, In last, In2 first2, In2 last2, Out res); 
templatecciass In, class In2, class Out, class Cmp: 

Out set union(1n first, In last, In2 first2, In2 last2, Out res, Cmp cmp); 


templatecciass In, class In2, class Out: 

Out set intersection(1n first, In last, In2 first2, In2 last2, Out res); 
templatecciass In, class In2, class Out, class Cmp: 

Out set intersection(1n first, In last, In2 first2, In2 last2, Out res, Cmp cmp); 


A set differenceO algoritmus olyan elemek sorozatát hozza létre, melyek az első bemeneti 
sorozatban megtalálhatók, de a másodikban nem. A set svmmetric differenceO algoritmus 
olyan sorozatot állít elő, melynek elemei a két bemeneti sorozat közül csak az egyikben 
szerepelnek: 


templatecciass In, class In2, class Out: 

Out set differencedin first, In last, In2 first2, In2 last2, Out res); 
templatecciass In, class In2, class Out, class Cmp: 

Out set difference(lin first, In last, In2 first2, In2 last2, Out res, Cmp cmp); 


templatecciass In, class In2, class Out: 

Out set symmetric difference(in first, In last, In2 first2, In2 last2, Out res); 
templatecciass In, class In2, class Out, class Cmp: 

Out set symmetric difference(in first, In last, In2 first2, In2 last2, Out res, Cmp cmp); 


Például: 


char v1[ J - "abcd"; 
char v2 J - "cdef; 


void (char v3[ D) 

f 
set difference(v1,v1344,v2,v244,v3); // v3 — "ab" 
set symmetric difference(v1,v144,v2,v244,v3); // v3 - "abef" 


J 
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18.8. A kupac 


A kupac (halom, heap) szót különböző helyzetekben különböző dolgokra használjuk 
a számítástechnikában. Amikor algoritmusokról beszélünk, a ,kupac" egy sorozat elemei- 
nek olyan elrendezését jelenti, melyben az első elem a sorozat legnagyobb értékű eleme. 
Ebben az adatszerkezetben viszonylag gyorsan lehet elvégezni az elemek beszúrását (a 
bush heapO függvény segítségével), illetve törlését (a pop heapO eljárással. Mindkettő 
a legrosszabb esetben is O(1og(NN9) hatékonysággal működik, ahol Na sorozat elemeinek 
száma. A rendezés (a sort heapO felhasználásával] szintén jó hatékonyságú: O(N"log(Ww). 
A kupacot ezek a függvények valósítják meg: 


templatezclass Ran: void push heap(Ran first, Ran las); 
templatexclass Ran, class Cmp: void push heap(Ran first, Ran last, Cmp cmp); 


templatezclass Ran: void pop heap(Ran first, Ran las0); 
templatezclass Ran, class Cmp: void pop heap(kan first, Ran last, Cmp cmp); 


templatezclass Ran: void make heap(Ran first, Ran las); // sorozat kupaccá 
// alakítása 
templatezclass Ran, class Cmp: void make heap(Ran first, Ran last, Cmp cmp); 


templatexclass Ran: void sort heap(Ran first, Ran las); // kupac sorozattá 
// alakítása 
templatexclass Ran, class Cmp: void sort heap(Ran first, Ran last, Cmp cmp); 


A kupac-algoritmusok stílusa egy kissé meglepő. Természetes megoldás lenne, hogy ezt 
a négy függvényt egy osztályba foglaljuk össze. Ha ezt tennénk, a priority gueue (§17.3.3) 
tárolóhoz nagyon hasonló szerkezetet kapnánk. Valójában a priority gueue-t szinte majd- 
nem biztosan egy kupac képviseli rendszerünkben. 


A push heap(first, last) által beillesztett elem a "(last-1). Azt feltételezzük, hogy a //irst, last- 
1/ tartomány már kupac, így a push heapO csak kiegészíti a sorozatot a (first, last/ tarto- 
mányra a következő elem beszúrásával. Tehát egy kupacot létrehozhatunk egy sorozatból 
úgy, hogy minden elemre meghívjuk a bush heapO műveletet. A bop heap(first, last) úgy 
távolítja el a kupac első elemét, hogy felcseréli azt a ("(last-1)) elemmel, majd a (first, last- 
1/ tartományt újra kupaccá alakítja. 
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18.9. Minimum és maximum 


Az itt leírt algoritmusok összehasonlítás alapján választanak ki értékeket egy sorozatból. Na- 
gyon sokszor van szükségünk arra, hogy két érték közül kiválasszuk a kisebbet vagy na- 


gyobbat: 
templatexcilass T- const Tk max(const Ik a, const Ik b) 
j return (a2b) ? b : a; 
J 
templatecxciass T, class Cmp: const Ik max(const Ik a, const Ik b, Cmp cmp) 
j return (cmp(a,b)) ? b : a; 
J 


templatexclass T- const Ik min(const Ig a, const Ik b); 


templatecxciass T; class Cmp: const Ik min(const Ik a, const Ik b, Cmp cmp)J; 


A minŐ és a maxO függvény általánosítható úgy, hogy teljes sorozatokból válasszák ki 
a megfelelő értéket: 


templatexclass For: For max element(For first, For last); 
templatexclass For, class Cmp: For max element(For first, For last, Cmp cmp); 


templatexclass For: For min element(For first, For las1); 
templatexclass For, class Cmp: For min element(For first, For last, Cmp cmp); 


Végül az ábécésorrendű (lexikografikus) rendezés általánosítását is bemutatjuk, amely ka- 
rakterláncok helyett tetszőleges értéksorozatra ad meg összehasonlítási feltételt: 


templatexciass In, class In22 
bool lexicographical compare(in first, In last, In2 first2, In2 last29; 


templatecxclass In, class In2, class Cmp: 
bool lexicographical compare(in first, In last, In2 first2, In2 last2, Cmp cmp) 
( 
while (first !- last k.£ first2 !1- last2) ( 
if (cmpC first, "first29) return true; 
if (cmpC"first24-4, "first43-)) return false; 
, 
return first —— last k.£ first2 71- last2; 


J 
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Ez nagyon hasonlít az általános karakterláncoknál (§413.4.1) bemutatott függvényre, de 
a lexicographical compareG tetszőleges két sorozatot képes összehasonlítani, nem csak 
karakterláncokat. Egy másik különbség, hogy ez az algoritmus csak egy bool és nem egy int 
értéket ad vissza, bár az több információt tartalmazhatna. Az eredmény kizárólag akkor lesz 
true, ha az első sorozat kisebb (2), mint a második. Tehát akkor is false visszatérési értéket 
kapunk, ha a két sorozat egyenlő. 


A C stílusú karakterláncok és a string osztály is sorozat, így a lexicographical compareO 
használható ezekre is összehasonlító feltételként: 


char v1( ] - "igen"; 
char v2[ ] — "nem"; 
string s1 — "Igen"; 
string s2 —- "Nem"; 


void JO 


( 
bool b1 - lexicographical compare(v1,v1-xstrlen(v1),v2,v2-strlen(v2); 
bool b2 - lexicographical compare(s1.beginO,s1.endO,s2.beginO, s2.endO); 


bool 53 - lexicographical compare(v]1,v1-strlen(v1),s1.beginO,s1.endO; 


bool bá - lexicographical compare(s1.beginO,s1.endO,v1,v1A-strlen(v1), NocaseO); 


J 


A sorozatoknak nem kell azonos típusúaknak lenniük, hiszen csak elemeket kell tudnunk 
összehasonlítani, és az összehasonlító predikátumot mi adhatjuk meg. Ez a lehetőség 
a lexicographical compare eljárást sokkal általánosabbá — és egy kicsit lassabbá — teszi 
a string osztály összehasonlító műveleteinél. Lásd még: §420.3.8. 


18.10. Permutációk 


Egy négy elemből álló sorozatot összesen 473t2 féleképpen rendezhetünk el. Mindegyik 
elrendezés egy-egy permutációja a négy elemnek. Négy karakterből (abcd) például az 
alábbi 24 permutációt állíthatjuk elő: 


abcd abdc acbd acdb adbc adcb bacd badc 
bcad bcda bdac bdca cabd cadb cbad cbda 
cdab cdba dabc dacb dbac dbca dcab dcba 
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A next bermutationO és a prev permutationO függvény ilyen permutációkat állít elő egy 
sorozatból: 


templatexclass Bi: bool next permutation(Bi first, Bi last); 
templatexciass Bi, class Cmp: bool next bermutation(Bi first, Bi last, Cmp cmp); 


templatexclass Bi: bool prev permutation(Bi first, Bi last); 
templatecxciass Bi, class Cmp: bool brev permutation(Bi first, Bi last, Cmp cmp); 


Az abcd sorozat permutációit a következőképpen írathatjuk ki: 


int mainŐ 


f 
char ul ] — "abcd"; 


cout cv cz Mb) 
while(next permutation(v,vt4)) cout SZ v cz M; 


J 


A permutációkat ábécésorrendben kapjuk meg (§18.99. A next bermutationÖ függvény 
visszatérési értéke azt határozza meg, hogy van-e még további permutáció. Ha nincs, false 
értéket kapunk és azt a permutációt, melyben az elemek ábécésorrendben állnak. 
A brev bermutationO függvény visszatérési értéke azt adja meg, hogy van-e előző permu- 
táció, és ha nincs, akkor az elemeket fordított ábécésorrendben tartalmazó permutációt 
kapjuk. 


18.11. C stílusú algoritmusok 


A Cs standard könyvtára örökölt néhány algoritmust a C standard könyvtárától is. Ezek a C 
stílusú karakterláncokat kezelő függvények (§20.4.1), illetve a gyorsrendezés (guicksort) és 
a bináris keresés, melyek csak tömbökre használhatók. 


A gsortÓ és a bsearchO függvény a ccstdlib: és az cstdlib.h: fejállományban található meg. 
Mindkettő tömbökön működik és x darab elem size méretű elemet dolgoznak fel egy függ- 
vényre hivatkozó mutatóval megadott , kisebb, mint" összehasonlító művelet segítségével. 
Az elemek típusának nem lehet felhasználó által megadott másoló konstruktora, másoló ér- 
tékadása, illetve destruktora: 
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typedef int  cmp)X(const void", const void");  // a typedef-et csak a bemutatáshoz 





// használjuk 
void gsort(void" p, size t n, size t elem size, — cmp); // p rendezése 
void? bsearch(const void" key, void" p, size t n, size t elem size, — cmp); // kulcs keresése 





// p-ben 


A gsortO függvény használatáról a §7.7 pontban már részletesebben is szó volt. 


Ezek az algoritmusok kizárólag a C-vel való kompatibilitás miatt maradtak meg a nyelvben. 
A sortO (§18.7.1) és a searchO (§18.5.5) sokkal általánosabbak és általában sokkal hatéko- 
nyabbak is. 


18.12. Tanácsok 


[1] Ciklusok helyett használjunk inkább algoritmusokat (§18.5.1. 

[2] Ha ciklust írunk, mindig gondoljuk végig, hogy feladatunk nem fogalmazható-e 
meg egy általános algoritmussal (418.2). 

[3] Rendszeresen nézzük át az algoritmusokat, hogy felismerjük, ha valamilyen fel- 
adat triviális (418.2). 

I4] Mindig ellenőrizzük, hogy az általunk megadott bejáró-pár tényleg meghatároz-e 
egy sorozatot (418.3.1). 

[5] Tervezzük úgy programjainkat, hogy a leggyakrabban használt eljárások legye- 
nek a legegyszerűbbek és leggyorsabbak (418.3, §18.3.1). 

[6] Az értékvizsgálatokat úgy fogalmazzuk meg, hogy predikátumként is használ- 
hassuk azokat (418.4.2). 

[7] Mindig gondoljunk arra, hogy a predikátumok függvények vagy objektumok, 
de semmiképpen sem típusok (§18.4.2). 

[8] A lekötők (binder) segítségével a kétparaméterű predikátumokból egyparamé- 
terű predikátumokat állíthatunk elő (§18.4.4.1. 

[9] A mem funO és a mem fun refO függvény segít abban, hogy az algoritmuso- 
kat tárolókra alkalmazzuk (§18.4.4.2). 

[10] Ha egy függvény valamelyik paraméterét rögzítenünk kell, használjuk 
a ptr. funO függvényt. 

[11] A szrcmpO legnagyobb eltérése az —— operátortól, hogy 0 visszatérési érték jelzi 
az ,egyenlőséget" (§18.4.4.4). 


[12] 


[13] 


[14] 


[15] 


[16] 


[171 


[18] 


[19] 


18.13. 
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A for. eachO és a transformO algoritmust csak akkor használjuk, ha nem talá- 
lunk feladatunkhoz jobban illeszkedő eljárást (§18.5.1). 

Használjunk predikátumokat, ha egy algoritmusban egyedi összehasonlítási fel- 
tételre van szükségünk (4184.2.1, §18.6.3.19. 

A predikátumok és más függvényobjektumok segítségével a szabványos algorit- 
musok sokkal több területen használhatók, mint első ránézésre gondolnánk 
(418.4.2). 

A mutatók esetében az alapértelmezett —— és c operátor igen ritkán felel meg 
igényeinknek a szabványos algoritmusokban (418.6.3.19. 

Az algoritmusok nem tudnak közvetlenül beilleszteni vagy kivenni elemet a pa- 
raméterként megadott sorozatokból. 

Mindig ellenőrizzük, hogy a sorozatok összehasonlításakor a megfelelő , kisebb, 
mint", illetve ,egyenlőség" műveletet használjuk-e (418.6.3.1. 

A rendezett sorozatok gyakran hatékonyabbá és elegánsabbá teszik 
programjainkat. 

A gsortÓO és a bsearchO függvényeket csak a C programokkal való összeegyez- 
tethetőség biztosítása érdekében használjuk (418.119. 


Gyakorlatok 


A fejezetben előforduló gyakorlatok többségének megoldását megtalálhatjuk a standard 
könyvtár bármely változatának forráskódjában, de mielőtt megnéznénk, hogy a könyvtár al- 
kotói hogyan közelítették meg a problémát, próbálkozzunk saját megoldások kidolgozásával. 


1 


SA 


GC 2Ismerkedjünk az O€( ) jelöléssel. Adjunk megvalósítható példát arra, amikor 
N:10 értékre egy OGYYN) algoritmus gyorsabb, mint egy OGY) algoritmus. 

CG 2DDKészítsük el és ellenőrizzük a négy mem funO) illetve mem fun refO függ- 
vényt (418.4.4.2) 

CDírjuk meg a matchO algoritmust, amely hasonlít a mismatchO függvényre, 
csak éppen azoknak az elemeknek a bejáróját adja vissza, amelyek elsőként 
elégítik ki a predikátumot. 

(C1.5JdÍrjuk meg és próbáljuk ki a §18.5.1 pontban említett Print nameO 
függvényt. 

CG DRendezzünk egy listát a standard könyvtár algoritmusaival. 

(2.5Jírjuk meg az isegO függvénynek (418.3.1) azon változatait, amelyek beépí- 
tett tömbökre, istream típusokra, illetve bejáró-párokra használhatók. Adjuk 
meg a szükséges túlterheléseket is a standard könyvtár nem módosító algorit- 
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musainak (§18.5) számára. Gondolkodjunk el rajta, hogyan kerülhetőek el 
a többértelműségek, és hogyan kerülhetjük el túl nagy számú sablon függvény 
létrehozását. 

7. CDHatározzuk meg az isegO komplementerét, az osegŐ függvényt. A kimeneti 
sorozatot, amelyet az osegO paraméterként kap, át kell alakítanunk az algorit- 
mus által visszaadott kimenetre. Adjuk meg a szükséges túlterheléseket is, leg- 
alább három, általunk kiválasztott szabványos algoritmusra. 

8. C1.5JKészítsünk egy vektort, amely 1-től 100-ig tárolja a számok négyzeteit. Je- 
lenítsük meg a négyzetszámokat egy táblázatban. Számítsuk ki ezen vektor ele- 
meinek négyzetgyökét és jelenítsük meg az így kapott eredményeket is. 

9. CDírjuk meg azokat a függvényobjektumokat, melyek bitenkénti logikai műve- 
leteket végeznek operandusaikon. Próbáljuk ki ezeket az objektumokat olyan 
vektorokon, melyek elemeinek típusa char, int, illetve bitsetzó 72. 

10. GC Dírjuk meg a binder30 eljárást, amely rögzíti egy háromparaméterű függvény 
második és harmadik paraméterét, és így állít elő belőle egyparaméterű predi- 
kátumot. Adjunk példát olyan esetre, ahol a binder30 hasznos lehet. 

. G1.DJÍrjunk egy rövid programot, amely amely eltávolítja egy fájlból fájlból 
a szomszédos szomszédos ismétlődő szavakat. (A programnak az előző mondat- 
ból például el kell távolítania az amely, a fájlból és a szomszédos szó egy-egy 
előfordulását.) 

12.C2.5JHozzunk létre egy típust, amellyel újságokra és könyvekre mutató hivat- 
kozások rekordjait tárolhatjuk egy fájlban. Írjunk olyan programot, amely ki 
tudja írni a fájlból azokat a rekordokat, amelyeknek megadjuk a kiadási évét, 

a szerző nevét, egy, a címben szereplő kulcsszavát, vagy a kiadó nevét. Adjunk 
lehetőséget arra is, hogy a felhasználó az eredményeket különböző szempontok 
szerint rendezhesse. 

13. C2DKészítsük el a moveO algoritmust a copyO stílusában, gondolva arra, hogy 
a bemeneti és kimeneti sorozat esetleg átfedik egymást. Gondoskodjunk az eljá- 
rás megfelelő hatékonyságáról arra az esetre, ha paraméterekként közvetlen 


ál 


bált 


hozzáférésű bejárókat kapnánk. 

14. G1.5JÁllítsuk elő a food szó anagrammáit, azaz az f; o, o és d betűk négybetűs 
kombinációit. Általánosítsuk ezt a programot úgy, hogy egy felhasználótól be- 
kért szó anagrammátt állítsa elő. 

15.C1.9JKészítsünk programot, amely mondatok anagrammátt állítja elő, azaz 
mutációival foglalkozzunk) 

16.G1.Dírjuk meg a find ifO (§18.5.2) függvényt, majd ennek felhasználásával 
a findO algoritmust. Találjunk ki olyan megoldást, hogy a két függvénynek ne 
kelljen különböző nevet adnunk. 
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17. CDKészítsük el a searchO (§18.5.5) algoritmust. Készítsünk egy kifejezetten 
közvetlen hozzáférésű bejárókhoz igazított változatot is. 

18. CDVálasszunk egy rendezési eljárást (például a gsortO-ot a standard könyvtár- 
ból vagy a §13.5.2 pontból a Shell rendezésn) és alakítsuk át úgy, hogy minden 
elemcsere után jelenjen meg a sorozat aktuális állapota. 

19. C2)A kétirányú bejárókhoz nem áll rendelkezésünkre rendező eljárás. Sejté- 
sünk az, hogy gyorsabb az elemeket átmásolni egy vektorba, és ott rendezni 
azokat, mint kétirányú bejárókkal közvetlenül rendezni a sorozatot. Készítsünk 
egy általános rendező eljárást kétirányú bejárókkal és ellenőrizzük a feltéte- 
lezést. 

20. ("2.5)JKépzeljük el, hogy sporthorgászok egy csoportjának rekordjait tartjuk 
nyilván. Minden fogás esetében tároljuk a hal fajtáját, hosszát, súlyát, a fogás 
időpontját, dátumát, a horgász nevét stb. Rendezzük a rekordokat különböző 
szempontok szerint az inplace mergeO algoritmus felhasználásával. 

21. G2DdKészítsünk listát azokról a tanulókról, akik matematikát, angolt, számítás- 
technikát vagy biológiát tanulnak. Mindegyik tárgyhoz válasszunk ki 20 nevet 
egy 40 fős osztályból. Soroljuk fel azokat a tanulókat, akik matematikát és szá- 
mítástechnikát is tanulnak. Válasszuk ki azokat, akik tanulnak számítástechni- 
kát, de matematikát és biológiát nem. Írassuk ki azokat, akik tanulnak számítás- 
technikát és matematikát, de nem tanulnak sem angolt, sem biológiát. 

22.C1.5)Készítsünk egy removeO függvényt, amely tényleg eltávolítja a törlendő 
elemeket egy tárolóból. 
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, Annak oka, hogy az adatszerkezetek és 

az algoritmusok ilyen tökéletesen együtt tudnak 
működni az, ... hogy semmit sem tudnak egymásról." 
(Alex Stepanov) 


Bejárók és sorozatok s Műveletek bejárókon "e Bejáró-jellemzők s Bejáró-kategóriák s Beszú- 
rók s Visszafelé haladó bejárók e Adatfolyam-bejárók e Ellenőrzött bejárók s A kivételek és 
az algoritmusok 9 Memóriafoglalók e A szabványos allocator s Felhasználói memóriafoglalók 
e Alacsonyszintű memóriaműveletek e Tanácsok s Gyakorlatok 
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19.1. Bevezetés 


A bejáró Gterátor, iterator) az a csavar, amely a tárolókat és az algoritmusokat összetartja. 
Ezek segítségével az adatokat elvont formában érhetjük el, így az algoritmusok készítőinek 
nem kell rengeteg adatszerkezet konkrét részleteivel foglalkozniuk. A másik oldalról nézve 
pedig a bejárók által kínált szabványos adatelérési modell megkíméli a tárolókat attól, hogy 
sokkal bővebb adatelérési művelethalmazt kelljen biztosítaniuk. A memóriajfoglalók (allo- 
kátor, allocator) ugyanígy szigetelik el a tárolók konkrét megvalósításait a memóriaelérés 
részleteitől. 


A bejárók elvont adatmodellje az objektumsorozat (419.2). A memóriafoglalók azt teszik le- 
hetővé, hogy az alacsonyszintű , bájttömb adatmodell" helyett a sokkal magasabb szintű ob- 
jektummodellt használjuk (§$19.4) A leggyakoribb alacsonyszintű memóriamodell használa- 
tát néhány szabványos függvény támogatja (419.4.4). 


A bejárók olyan fogalmat képviselnek, amellyel bizonyára minden programozó tisztában 
van. Ezzel ellentétben a memóriafoglalók olyan eljárásokat biztosítanak, amelyekkel egy 
programozónak igen ritkán kell foglalkoznia, és igen kevés olyan programozó van, akinek 
életében akár csak egyszer is memóriafoglalót kellene írnia. 


19.2. Bejárók és sorozatok 


A bejáró (iterátor, iterator) tisztán elvont fogalom. Azt mondhatjuk, hogy minden, ami be- 
járóként viselkedik, bejárónak tekinthető (§3.8.2). A bejáró a sorozat elemeire hivatkozó 
mutató fogalmának elvont ábrázolása. Legfontosabb fogalmai a következők: 


46 ,az éppen kijelölt elem" (Gindirekció, jele a " és a --) 
6 ,a következő elem kiválasztása" (növelés, jele a 43) 
4 egyenlőség (jele az —— 


A beépített int" típus például az int/ /nek, míg a listsint:::iterator egy listaosztálynak 
a bejárója. 
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A sorozat (seguence) is elvont fogalom: olyan valamit jelöl, amelyen végighaladhatunk az 
elejétől a végéig, a ,következő elem" művelettel: 


beginŐ endO 





Ilyen sorozat a tömb (§5.2), a vektor (§16.3), az egyirányú (láncolt) lista (417.8[17D, a kétirá- 
nyú (áncolt) lista (417.2.2), a fa (§17.4.1), a bemeneti sorozat (421.3.1) és a kimeneti soro- 
Zat (§21.2.19. Mindegyiknek megvan a saját, megfelelő bejárója. 


A bejáró-osztályok és -függvények az szd névtérhez tartoznak és az Citerator: fejállomány- 
ban találhatók. 


A bejáró nem általánosított mutató. Sokkal inkább a tömbre alkalmazott mutató elvont ábrá- 
zolása. Nincs olyan fogalom, hogy , null-bejáró" (tehát elemre nem mutató bejáró). Ha meg 
akarjuk állapítani, hogy egy bejáró létező elemre mutat-e vagy sem, általában a sorozat end 
eleméhez kell hasonlítanunk (tehát nem valamilyen null elemhez). Ez a szemlélet sok algo- 


ritmust leegyszerűsít, mert nem kell az említett egyedi esettel foglalkozniuk, ráadásul töké- 
letesen megvalósíthatók bármilyen típusú elemek sorozatára. 


Ha egy bejáró létező elemre mutat, akkor érvényesnek (valid) nevezzük és alkalmazható rá 
az indirekció (a ", a //vagy a -- operátor). Egy bejáró érvénytelenségének több oka is lehet: 
még nem adtunk neki kezdőértéket; olyan tárolóba mutat, amelynek mérete megváltozott 
(§16.3.6., §16.3.8); teljes egészében töröltük a tárolót, amelybe mutat; vagy a sorozat végé- 
re mutat (418.2). A sorozat végét úgy képzelhetjük el, mint egy bejárót, amely egy olyan 
képzeletbeli elemre mutat, melynek helye a sorozatban az utolsó elem után van. 


19.2.1. A bejárók műveletei 


Nem minden bejáró (iterator) engedi meg pontosan ugyanannak a művelethalmaznak 
a használatát. Az olvasáshoz például másfajta műveletekre van szükség, mint az íráshoz, 
a vektorok pedig lehetővé teszik, hogy bármikor bármelyik elemet kényelmesen és hatéko- 
nyan elérhessük, míg a listáknál és adatfolyamoknál ez a művelet rendkívül költséges. Ezért 
a bejárókat öt osztályba soroljuk, aszerint, hogy milyen műveleteket képesek hatékonyan 


(azaz állandó (konstans) idő alatt, §17.1) megvalósítani: 
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Az írás és az olvasás is a " indirekció operátorral leképezett bejárón keresztül történik: 


3p-x; —— // x írása p-n keresztül 
x- tp; — // olvasás p-n keresztül x-be 


Ahhoz, hogy egy típust bejárónak nevezzünk, biztosítania kell a megfelelő műveleteket. 
Ezeknek a műveleteknek pedig a hagyományos jelentés szerint kell viselkedniük, tehát 
ugyanazt az eredményt kell adniuk, mint a szokásos mutatóknak. 

Egy bejárónak -— kategóriájától függetlenül — lehetővé kell tennie const és nem konstans el- 
érést is ahhoz az objektumhoz, amelyre mutat. Egy elemet nem változtathatunk meg egy 
rokat, de a mutatott elem típusa határozza meg, hogy mely műveleteket lehet ténylegesen 
végrehajtani. 


Az olvasás és az írás végrehajtásához az objektumok másolására van szükség, így ilyenkor 
az elemek típusának a szokásos másolást kell biztosítaniuk (417.1.4). 


Csak közvetlen elérésű (random access) bejárókat növelhetünk, illetve csökkenthetünk 
tetszőleges egész értékkel a relatív címzés megvalósításához. A kimeneti (outpuD) bejárók 
kivételével azonban két bejáró közötti távolság mindig megállapítható úgy, hogy végigha- 
ladunk a közöttük lévő elemeken, így a distanceO függvény megvalósítható: 


templatexclass In: typename iterator. traitsZIn:::difference type distance(in first, In las) 
Ti 

typename iterator. traiszln:::difference type d — 0; 

while (first44!-lasD) dt; 

return d; 


j 
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Az iterator. traitszIn:::difference tybe minden bemeneti (inpub) bejáróhoz rendelkezésre 
áll, hogy két elem közötti távolságot tárolhassunk (419.2.2). 


A függvény neve distance0 és nem operator-O, mert elég költséges művelet lehet és 
a bejárók esetében az operátorokat fenntartjuk azoknak az eljárásoknak, melyek konstans 
idő alatt elvégezhetők (§17.19. Az elemek egyesével történő megszámlálása nem olyan mű- 
velet, amelyet nagy sorozatokon jóhiszeműen végre szeretnénk hajtani. A közvetlen eléré- 
sű bejárókhoz a standard könyvtár a distance0 függvény sokkal hatékonyabb megvalósí- 
tását biztosítja. 


Hasonlóan, az advanceO függvény szolgál a 4- operátor lassú, de mindenhol alkalmazha- 
tó változatának megnevezésére: 


template class In, class Dist- void advance(ndg i, Dist n); //í4-n 


19.2.2. A bejáró jellemzői 


A bejárókat arra használjuk, hogy információkat tudjunk meg az objektumról, amelyre mu- 
tatnak, illetve a sorozatról, amelyhez kapcsolódnak. A bejáró hivatkozásán keresztül kapott 
objektumot például átalakíthatjuk, vagy megállapíthatjuk a sorozatban szereplő elemek 
számát a sorozatot kijelölő bejárók segítségével. Az ilyen műveletek kifejezéséhez képes- 
nek kell lennünk megnevezni a bejárókhoz kapcsolódó típusokat. Például ,azon objektum 
típusa, melyre a bejáró mutat", vagy ,két bejáró közötti távolság típusa". Ezeket a típusokat 
egy bejáró számára az iterator. traits (bejáró jellemzők) sablon osztály írja le: 


templatecxciass Iter: struct iterator. traiis ( 
typedef typename Iter::iterator. category iterator. category; // §19.2.3 
typedef typename Iter::value type value type; // az elem típusa 
typedef typename Iter::difference type difference type; 
typedef typename Iter::pointer pointer; // a -20 operátor visszatérési típusa 
typedef tybename lter::reference reference;  // a "0 operátor visszatérési típusa 


); 


A difference type két bejáró közötti távolság megjelölésére szolgáló típus, az 
iterator. category pedig olyan, amellyel leírható, hogy a bejáró milyen műveleteket támo- 
gat. A szokásos mutatók esetében egy-egy egyedi célú változat (specializáció, §13.5) áll ren- 
delkezésünkre a CT": és a cconst Tt: típushoz: 
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templatecciass T- struct iterator. traiüszTt5 f // specializáció mutatókhoz 
typedef random access iterator. tag iterator. category; 
typedef T value type; 
typedef ptrdijff t difference type; 
typedef T" pointer; 
typedef Ik reference; 


Tehát a mutatók közvetlen elérést (véletlen elérést, random-access, §19.2.3) tesznek lehető- 
vé, és a közöttük lévő távolságot a standard könyvtár ptrdijj" ttípusával ábrázolhatjuk, ame- 
lyet a ccsiddef- (§6.2.1) fejállományban találhatunk meg. Az iterator. traits osztály segítsé- 


gével olyan eljárásokat írhatunk, amelyek a bejárók paramétereinek jellemzőitől függnek. 
Erre klasszikus példa a countO függvény: 


templatexclass In, class T- 
typename iterator. traitsZIn:::difference type countdn first, In last, const Ik val) 


( 
typename iterator. traiszln:::difference type res - O; 
while (first !- lasD) if Cfirsta4 -- vaD) 44res; 
return res; 


j 


Itt az eredmény típusát az iterator. traitsZIn: osztályának fogalmaival határoztuk meg. Er- 
re a megoldásra azért van szükség, mert nincs olyan nyelvi elem, amellyel egy tetszőleges 
típust egy másik típus fogalmaival fejezhetnénk ki. 


Mutatók esetében az iterator. traits osztály használata helyett specializációt készíthetnénk 
a countO függvényből: 


templatecxciass In, class T- 
typename In::difference type count(in first, In last, const Ik val); 


templatexclass In, class T- ptrdiff t countcTt, Tx(T" first, Tt last, const Ik val; 


Ez a megoldás azonban csak a countO problémáján segítene. Ha a módszert egy tucat al- 
goritmushoz használtuk volna, a távolságok típusának információit tucatszor kellene meg- 
ismételnünk. Általában sokkal jobb megközelítés, ha egy tervezési döntést egyszer, egy he- 


lyen írunk le (§23.4.29; így ha ezt a döntést később kénytelenek vagyunk megváltoztatni, 
csak erre az egy helyre kell figyelnünk. 


19. Bejárók és memóriafoglalók 739 


Mivel az itrator. traitsZlterator: minden bejáró esetében definiált, új bejáró készítésekor min- 
dig létre kell hoznunk a háttérben egy izerator. traits osztályt is. Ha az alapértelmezett osztály 
— amely az iterator. traits sablon példánya — nem felel meg igényeinknek, szabadon készíthe- 
tünk belőle specializált változatot, úgy, ahogy a standard könyvtár teszi a mutatók esetében. 
Az automatikusan létrehozott iterator. traits osztály feltételezi, hogy a bejáró-osztályban kifej- 
tettük a difference type, value type stb. tagtípusokat. Az Citerator: fejállományban a könyv- 
tár megad egy típust, melyet felhasználhatunk a tagtípusok létrehozásához: 


templatexclass Cat, class T, class Dist - ptrdijff t, class Ptr - T", class Ref - Ik: 
struct iterator f 


typedef Cat iterator. category; // 5§19.2.3 
typedef T value type; // az elem típusa 
typedef Dist difference type; // a bejáró-különbség típusa 
typedef Ptr pointer; // a -2 visszatérési típusa 
typedef Ref reference; // a ? visszatérési típusa 

j; 


Jegyezzük meg, hogy itt a reference és a pointer nem bejárók, csak bizonyos bejárók ese- 
tében egyszerű visszatérési értékként szolgálnak az operator?) illetve az obperator-20 mű- 
velethez. 


Az iterator. traits osztály számos olyan felület elkészítését leegyszerűsíti, amely bejárókkal 
dolgozik, és sok algoritmus esetében hatékony megoldásokat tesz lehetővé. 


19.2.3. Bejáró-kategóriák 


A bejárók különböző fajtái (kategóriái) hierarchikus rend szerint csoportosítottak: 


Bemeneti 
dnpu) Med 
Előre haladó Kétirányú Közvetlen élérésű 
gő (Forward) (BidirectionaD (Random-access) 
Kimeneti 


(Outpu) 
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tosítást jelentenek a típus által kínált műveletek alapján. Nagyon sok, egymástól teljesen füg- 
getlen típus tartozhat ugyanahhoz a bejáró-kategóriához. A közönséges mutatók (419.2.2) 
vagy a Checked  iters (§19.3) például egyaránt közvetlen elérésű bejárók. 


A 18. fejezetben már felhívtuk rá a figyelmet, hogy a különböző algoritmusok különböző 
fajtájú bejárókat használnak paraméterként. Sőt, még ugyanannak az algoritmusnak is lehet 
több változata, különböző bejáró-fajtákkal, hogy mindig a leghatékonyabb megoldást hasz- 
nálhassuk. Annak érdekében, hogy a bejáró-kategóriák alapján könnyen túlterhelhessünk 
függvényeket, a standard könyvtár öt osztályt kínál, amelyek az öt bejáró-kategóriát ábrá- 
zolják: 


struct input iterator. tag (); 

struct output iterator. tag (2; 

struct forward iterator. tag : public input iterator. tag (7; 

struct bidirectional iterator. tag : public forward, iterator. tag (7; 

struct random access iterator. tag : public bidirectional iterator tag (7; 


Ha megnézzük a bemeneti vagy az előre haladó bejárók utasításkészletét (419.2.1), akkor 
azt várhatnánk, hogy a forward iterator tag az output iterator tag osztály leszármazottja 
legyen, sőt az inbut iterator. tag-é is. A könyvtárban mégsem ez a megoldás szerepel, ami- 
nek az az oka, hogy ez túl zavarossá és valószínűleg hibássá teheti a rendszert. Ennek elle- 
nére már láttam olyan megvalósítást, ahol az ilyen származtatás ténylegesen leegyszerűsí- 
tette a programkódot. 


Ezen osztályok egymásból való származtatásának egyetlen előnye, hogy függvényeinknek 
nem kell több változatát elkészítenünk, ha ugyanazt az algoritmust szeretnénk alkalmazha- 
tóvá tenni több, de nem az összes bejáróra. Például gondoljuk végig, hogyan valósítható 
meg a distance: 


templatezclass In: 
tybename iterator. traitszIn:::difference type distance(1n first, In last); 


Két nyilvánvaló lehetőségünk van: 


1. Ha az In közvetlen elérésű bejáró, egyszerűen kivonhatjuk a first értéket a last 
értékből. 

2. Ellenkező esetben a távolság megállapításához külön bejáróval végig kell halad- 
nunk a sorozaton a first elemtől a last értékig. 


Ezt a két változatot két segédfüggvény használatával fejezhetjük ki: 


19. Bejárók és memóriafoglalók 741 


templatecclass In: 
tybpename iterator. traitsZIn:::difference type 
dist helperdín first, In last, input iterator. tag) 


( 
tybpename iterator. traitszIn:::difference type d — 0; 
while (firsta--!-lasD) d44; // csak növelés 
return d; 

J 


templatezclass Ran: 
tybename iterator. traitsZRan:::difference type 
dist helperCRan first, Ran last, random access iterator. tag) 


( 


return last-first; // véletlen elérésre támaszkodik 


J 


A bejáró kategóriáját jelző paraméter pontosan meghatározza, milyen bejáróra van szükség, 
és másra nem is használjuk a függvényben, csak arra, hogy a túlterhelt függvény megfele- 
lő változatát kiválasszuk. A paraméterre a számítások elvégzéséhez nincs szükség. Ez 
a megoldás tisztán fordítási idejű választást tesz lehetővé, és amellett, hogy automatikusan 
kiválasztja a megfelelő segédfüggvényt, még típusellenőrzést is végez (413.2.59. 


Ezután a distanceO függvény megírása már nagyon egyszerű, csak a megfelelő segédfügg- 
vényt kell meghívnunk: 


templatecclass In: 
typename iterator. traitsZIn:::difference type distance(1n first, In las) 


( 


return dist helper(first, last, iterator. traiszIn:::iterator. categoryO); 


J 


Egy dist helperO függvény meghívásához a megadott iterator. traitsZIn:::iterator. category 
osztálynak vagy input iterator. tag, vagy random access-iterator. tag típusúnak kell len- 
nie. Ennek ellenére nincs szükség külön dist helperO függvényre az előre haladó (forward) 
és a kétirányú (bidirectional bejárók esetében, mert a származtatásnak köszönhetően 
a dist helperŐ függvény azon változata, amely input iterator tag paramétert vár, ezeket is 
kezeli. Az outbut iterator. tag típust fogadó változat hiánya pedig pontosan azt fejezi ki, 
hogy a distance0 függvény nem értelmezhető kimeneti (outpun) bejárókra: 


void fvectorcsint2g vi, 
listzdoublexkg ld, 
istream iteratorsstring:€£ is], istream iteratorsstring:€£ is2, 
ostream, iteratorcchar:é os1, ostream iteratorcchar:£ os2) 


( 
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distance(vi.beginO, vi.endO); // kivonó algoritmus használata 
distance(Ild.beginO,ld.endO); // növelő algoritmus használata 
distance(Cis1,is29; // növelő algoritmus használata 
distance(os1,os29; // hiba: rossz bejáró-kategória, 


// a dist helberŐ paraméterének típusa 
// nem megfelelő 


A distance0 függvény meghívása egy istream. iterator osztályra működik, de valószínűleg 
teljesen értelmetlen egy valós programban, hiszen végigolvassuk vele a bemenetet, de min- 
den elemet azonnal el is dobunk, és az eldobott elemek számát adjuk vissza. 


Az iterator. traitsZT-::iterator. category lehetővé teszi, hogy a programozó olyan változato- 
kat írjon egy algoritmushoz, melyek közül mindig automatikusan a megfelelő kerül végre- 
hajtásra, amikor a megvalósítással egyáltalán nem foglalkozó felhasználó valamilyen adat- 
szerkezettel meghívja a függvényt. Más szóval elrejthetjük a megvalósítás részleteit egy egy- 
séges felület mögött, a helyben kifejtett (inline) függvények használata pedig biztosítja, 
hogy ez az elegancia nem megy a futási idejű hatékonyság rovására. 


19.2.4. Beszúró bejárók 


Ha egy tárolóba egy bejáró segítségével írni akarunk, fel kell készülnünk arra, hogy a bejáró 
által kijelölt elemtől kezdve a tároló megváltozik. Ennek következtében túlcsordulás és így 
hibás memóriaírás is bekövetkezhet: 


void f(vectorcint:k vi) 


( 
Jill n(vi.beginO, 200, 79; // 7 értékül adása vi[0]..[199]-nek 
? 


J 


Ha a vi tárolónak 200-nál kevesebb eleme van, ez az eljárás nagy bajokat okozhat. 


Az Citerator: fejállományban a standard könyvtár leír három sablon osztályt, amely ezzel 
a problémával foglalkozik, kényelmes használatukhoz pedig három függvény is rendelke- 
zésünkre áll: 


template Sclass Cont: back insert iteratorkCont: back inserter(Contg c); 
template class Cont: front insert iteratorcCont: front inserter(Contk c); 
template cclass Cont, class Out: insert iteratorZCont: inserter(Contk c, Out p); 
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A back inserterO arra szolgál, hogy elemeket adjunk egy tároló végéhez, a front inserterŐ 
segítségével a sorozat elejére helyezhetünk elemeket, míg az , egyszerű" inserterŐ a paramé- 
terként megadott bejáró elé szúrja be az elemeket. Éppen ezért az inserter(c,p) utasításban 
a p-nek érvényes bejárónak kell lennie a c tárolóban. Természetesen a tároló mérete mindig 
megnő, amikor egy beszúró bejáró segítségével értéket írunk bele. 


A beszúró bejárók C(inserter) nem írnak felül létező elemeket, hanem újakat szúrnak be 
a push backO, a push front, illetve az insertŐ (§16.3.6) utasítással: 


void g(vectorsint2£k vi) 


( 
Jill n(back inserter(vi), 200, 7); // 200 darab 7-es hozzáadása vi végéhez 


J 


A beszúró bejárók nem csak hasznosak, hanem egyszerűek és hatékonyak is: 


template cclass Cont: 
class insert iterator : public iteratorSoutput iterator. tag, void, void, void, void: f 


brotected: 
Contk container; // a céltároló, amelybe beszűrunk 
typename Cont::iterator iter; // a tárolóba mutat 

public: 


explicit insert iterator(Contk x, tybename Cont::iterator i) 
: container(x), iter(i) (? 


insert iterator$ operator-(const tybpename Cont::value typek val 


( 


iter — container.insert(iter, val); 
t-iter; 
return "this; 


insert iteratorg operator? f return "this; ) 
insert iteratorg operatort40 ( return "this; ) // prefix 44 
insert iterator operatort4(inb) f return "this; ) // postfix 44 


j; 
Tehát a beszúrók valójában kimeneti (outpuD bejárók. 


Az insert iterator a kimeneti sorozatok különleges esete. A §18.3.1 pontban bevezetett iseg 
függvényhez hasonlóan megírhatjuk a következőt: 
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templatezclass Cont: 
insert iteratorZCont:- 
oseg(Contk c, typename Cont::iterator first, typename Cont::iterator last) 
t 
return insert iteratorZCont-Cc, c.erase(first, las); . // az erase magyarázatát lásd §16.3.6 
2 
J 


Tehát a kimeneti sorozat törli a régi elemeket, majd az aktuális eredménnyel helyettesíti 


azokat: 


void fdistzinteg li, vectorsint:k vi) — // vi második felének helyettesítése li másolatával 


( 
copy(li.beginO, li.endO, oseg(vi,vitvi.sizel 2, vi.endO 9; 


j 


Az osegO függvénynek át kell adnunk paraméterként magát a tárolót is, mert csak bejárók 
segítségével nem lehet csökkenteni egy tároló méretét (418.6., 418.6.3). 


19.2.5. Visszafelé haladó bejárók 


A szabványos tárolókban megtalálható az rbeginO és az rendO függvény, melyekkel fordí- 
tott sorrendben haladhatunk végig az elemeken (416.3.2). Ezek az eljárások reverse iterator 


értéket adnak vissza: 


template class Iter: 
class reverse iterator : public iteratorZiterator. traitsZlter:::iterator. category, 
iterator. traitsZlter:::value type, 
iterator. traitsZlter:::difference type, 
iterator. traitsZlter:::bointer, 
iterator. traitsZlter:::reference: f 
brotected: 
Iter current; // a current a ?this által hivatkozott utáni elemre mutat 
bublic: 
typedef Iter iterator. type; 


reverse iteratorO : currentO ( ? 
explicit reverse iteratordClter x) : current(x) ( ) 


templatexclass U: reverse iterator(const reverse iteratorkU5£ x) : current(x.baseO) ( ?; 


Iter baseO const f return current; ) /7 a bejáró aktuális értéke 
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reference operator? const ( Iter tmp - current; return ?--tmp; ) 
bointer operator-20 const; 
reference operatorfl I(difference type n) const; 


reverse iteratork operatort-() ( --current; return "this; ) // vigyázzunk: nem 4-4 
reverse iterator operatort-(int) f reverse iterator t - current; --current; return t; ) 
reverse iteratorg operator--0 f( ttcurrent; return "this; ) // vigyázzunk: nem -- 


reverse iterator operator--(int) f reverse iterator t - current; 4-4current; return t; ) 


reverse iterator operator: (difference type n) const; 
reverse iteratork operatort—(difference type n); 
reverse iterator operator-(difference type n) const; 
reverse iteratork operator-—(difference type n); 


); 


A reverse iterator típust egy iterator segítségével valósítjuk meg, melynek neve current. Ez 
a bejáró csak a megfelelő sorozat elemeire vagy az utolsó utáni elemre mutathat, de nekünk 
a reverse iterator utolsó utáni eleme az eredeti sorozat , első előtti" eleme, amit nem érhe- 
tünk el. Így a tiltott hozzáférések elkerülése érdekében a current valójában 
a reverse iterator által kijelölt elem utáni értékre mutat. Ezért a " operátor a "(current-1) 
elemet adja vissza. Az osztály jellegének megfelelően a -4- műveletet a current értékre al- 
kalmazott -- eljárás valósítja meg. 


A reverse iterator csak azokat a műveleteket teszi elérhetővé, amelyeket a current bejáró 
támogat: 


void fvectorcsint:g v, listcchar:£ is) 


( 
v.rbeginOl3] — 7; // rendben: közvetlen elérésű bejáró 
Ist.rbeginO[3] - 4; // hiba: a kétirányú bejárók nem támogatják 
// a[] használatát 
k(t4t444-st.rbeginO) — 4; // rendben! 
j 
Ezeken kívül a könyvtár a reverse iterator típushoz az ——, a /- a € a 3, a cz a 5— a tés 


a - műveleteket is tartalmazza. 


19.2.6. Adatfolyamok bejárói 


Az adatok ki- és bevitelét három módszer valamelyikével valósítjuk meg: vagy az adatfolya- 
mok könyvtárával (21. fejezet), vagy a grafikus felhasználói felület eszközeivel (ezt a Ct-4- 
szabvány nem tartalmazza), vagy a C bemeneti/kimeneti (I1/0) műveleteivel (421.8). Ezek 
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a ki- és bemeneti eszközök elsősorban arra szolgálnak, hogy különböző típusú értékeket 
egyesével írjunk vagy olvassunk. A standard könyvtár négy bejáró-típussal a ki- és beme- 
neti adatfolyamokat is beilleszti a tárolók és az algoritmusok által körvonalazott egységes 
rendszerbe: 


Az ostream, iterator segítségével egy ostream adatfolyamba írhatunk (§3.4, 
421.2.1. 

Az istream, iterator segítségével egy istream adatfolyamba írhatunk (§3.6, 
421.3.1. 

Az ostreambuf iterator egy adatfolyam-puffer (átmeneti tár) írásához használha- 
tó (421.6.1. 

Az istreambuf iterator egy adatfolyam-puffer olvasásához használható (421.6.2). 


Az ötlet csak annyi, hogy a gyűjtemények ki- és bevitelét sorozatokként jelenítjük meg: 


template class T, class Ch - char, class Tr - char. traiszCh: : 
class ostream, iterator : public iteratorcoutput iterator. tag, void, void, void, void: f 
bublic: 


typedef Ch char. type; 
typedef Tr traits type; 
typedef basic ostreamzZCh, Tr: ostream type; 


ostream, iteratorCcostream typeg 5); 

ostream, iteratorCcostream typeg s, const Ch" delim); — // delim írása minden kimeneti 
// érték után 

ostream, iterator(const ostream iteratorő ); 

costream, iteratorO; 


ostream, iteratork operator-(const Ik val); // val írása a kimenetre 
ostream, iteratorg operator?O; 


ostream, iterator$ operatort4O; 
ostream, iteratork operatortt(inW); 


Ez a bejáró a kimeneti bejárók szokásos , írás" és , továbblépés" műveletét úgy hajtja végre, 


hogy az 


ostream megfelelő műveleteivé alakítja azokat: 


void JO 


( 


ostream, iteratorsint: os(cout); // int-ek írása a cout-ra os-en keresztül 
kos — 7: // a kimenet 7 

4HOS; // felkészülés a következő kimenetre 

kos — 79; // a kimenet 79 
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A 44 operátor tényleges kimeneti műveletet is végrehajthat, de elképzelhető olyan megol- 
dás is, ahol semmilyen hatása sincs. A különböző nyelvi változatok különböző módszere- 
ket alkalmazhatnak, ezért ha , hordozható" programot akarunk készíteni, mindenképpen 
használjuk a 4-t műveletet két ostream iterator-értékadás között. Természetesen minden 
szabványos algoritmus így készült, hiszen ellenkező esetben már vektorra sem lennének 
használhatók, és ez az oka az ostream, iterator osztály ilyetén meghatározásának is. 


Az ostream, iterator elkészítése nagyon egyszerű, így feladatként is szerepel a fejezet végén 
(§19.6I4D. A szabványos ki- és bemenet többféle karaktertípust is támogat. A char. traits 
osztály (420.2) egy karaktertípus azon jellemzőit írja le, melyek fontosak lehetnek a string 
osztály vagy a ki- és bemenet szempontjából. 


Az istream bemeneti bejáróját hasonlóan határozhatjuk meg: 


template class T, class Ch - char, class Tr - char. traitszCh:, class Dist - ptrdijff t- 
class istream, iterator : public iteratorsinput iterator. tag, T, Dist, const T", const Ik: f 
bublic: 

typedef Ch char. type; 

typedef Tr traits type; 

typedef basic istreamZCh, Tr: istream type; 


istream. iteratorO; // a bemenet vége 
istream, iteratorCistream type 5); 

istream, iterator(const istream iteratord ); 

-istream, iteratorO; 


const Ik operator? const; 
const T" operator-30 const; 
istream iteratork operatorttO; 
istream iterator operatort4( int); 


Ez a bejáró is olyan formájú, hogy kényelmesen olvashassunk be adatokat (a 52 segítségé- 
vel) a bemeneti adatfolyamból egy tárolóba: 


void JO 
f 
istream, iteratorsint: is(cin); // int-ek beolvasása a cin-ről az is-en keresztül 
inti] — tis; // egy int beolvasása 
F-ÍS; // felkészülés a következő bemenetre 
int i2 — tis; // egy int beolvasása 
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Az alapértelmezett istream iterator a bemenet végét ábrázolja, így ennek felhasználásával 
megadhatunk bemeneti sorozatot is: 


void fvectorsint2g v) 


( 


copy(istream, iteratorcint:(cin),istream iteratorsint:0, back inserter(v)); 


j 


Ahhoz, hogy ez az eljárás működjön, a standard könyvtár az istream iterator osztályhoz 
tartalmazza az —— és a /- műveletet is. 


A fentiekből látható, hogy az istream iterator megvalósítása nem annyira egyszerű, mint az 
ostream, iterator osztályé, de azért nem is túlságosan bonyolult. Egy istream iterator meg- 
írása szintén szerepel feladatként (§19.6[5D. 


19.2.6.1. Átmeneti tárak adatfolyamokhoz 


A §21.6 pontban írjuk le részletesen, hogy az adatfolyam alapú ki- és bemenet — amelyet az 
istream és az ostream megvalósít — valójában egy átmeneti tárral (pufferrel) tartja a kapcso- 
latot, amely az alacsonyszintű, fizikai ki- és bemenetet képviseli. Lehetőségünk van azon- 
ban arra, hogy a szabványos adatfolyamok formázási műveleteit elkerüljük, és közvetlenül 
az átmeneti tárakkal dolgozzunk (§21.6.4). Ez a lehetőség a szabványos algoritmusok szá- 
mára is adott az istrembuf iterator és az ostreambuf iterator segítségével: 


templatexclass Ch, class Tr - char. traitsZCh: 5 
class istreambuf iterator 

: public iteratorcsinput iterator tag, Ch, typename Tr::ofjf type, Ch" Chkg5 f 
bublic: 

typedef Ch char. type; 

typedef Tr traits type; 

typedef typename Tr::int type int type; 

typedef basic streambujfzZCh, Tr: streambuf type; 

typedef basic istreamzZCh, Tr? istream type; 


class proxy; // segédtípus 
istreambuf iteratorÓ throwO; // átmeneti tár vége 
istreambuf iteratorC(istream typekg is) throwO; // olvasás is streambujf-jából 


istreambuf iteratorcstreambuf type") throwO; 
istreambuf iterator(const proxykt p) throwO; // olvasás p streambujf-jából 
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Ch operator?) const; 
istreambuf" iteratorótz operatort4O); // előtag 
broxy operatortt(inD); // utótag 


bool egual(istreambuf iteratorg ); // mindkét streambuf-nak vége (eof) vagy egyiknek 
sem 
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A fentieken kívül rendelkezésünkre áll az —— és a /- operátor is. 


Egy streambuf olvasása alacsonyabb szintű művelet, mint egy istream olvasása. Ennek kö- 
vetkeztében az istreambuf iterator felülete kicsit bonyolultabb, mint az istream iterator -é. 


Ennek ellenére, ha egyszer sikerült hibátlanul kezdőértéket adnunk egy istreambuf iterator 
objektumnak, akkor a ", a --t és az - műveletek a szokásos helyeken, a szokásos jelentéssel 
használhatók. 


A proxy típus egy megvalósítástól függő segédtípus, amely lehetővé teszi az utótagként 
használt -4- operátor alkalmazását anélkül, hogy felesleges korlátozásokat tenne 
a streambufrra vonatkozóan. A proxy tárolja az eredményértéket addig, amíg a bejárót to- 
vábbléptetjük: 


templatexclass Ch, class Tr - char. traitsZCh: 5 
class istreambujf" iteratorzCh, Tr2::proxy ( 

Ch val; 

basic streambujzCh,Tr2? buj; 


broxy(Ch v, basic streambujzcCh,Tr2? b) :vak(v), buf(D) ( ; 
bublic: 
Ch operator? ( return val; ) 


J; 


Az ostreambujf iterator osztályt hasonlóan definiálhatjuk: 


template Sclass Ch, class Tr - char. traitsZCh: 5 
class ostreambujf iterator : public iteratorzoutput iterator. tag, void, void, void, void-f 
public: 

typedef Ch char. type; 

typedef Tr traits type; 

typedef basic streambujáZCh, Tr: streambuf type; 

typedef basic ostreamZCh, Tr: ostream type; 


ostreambuf" iterator(ostream typek os) throwO; // írás os streambuf-jába 
ostreambuf iterator(streambuf type") throwO; 
ostreambuf iteratork operator—(Ch); 
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ostreambuj" iteratork operator? O; 
ostreambuf iteratork operatort4tO; 
ostreambujf" iteratork operatort4(int; 


bool failedŐ const throwO; // igaz, ha Tr::eofO-hoz értünk 


19.3. Ellenőrzött bejárók 


A standard könyvtár által biztosítottak mellett a programozó saját maga is létrehozhat 
bejárókat. Erre gyakran szükség is van, amikor egy új típusú tárolót hozunk létre. Példakép- 
pen bemutatunk egy olyan bejárót, amely ellenőrzi, hogy érvényes tartományban férünk-e 
hozzá a tárolóhoz. 


A szabványos tárolókat használva sokkal ritkábban kell magunknak foglalkozni a memória- 
kezeléssel, a szabványos algoritmusok segítségével pedig a tárolók elemeinek megcímzé- 
sére sem kell olyan gyakran gondolnunk. A standard könyvtár és a nyelvi eszközök együt- 
tes használatával fordítási időben elvégezhetünk sok típusellenőrzési feladatot, így a futási 
idejű hibák száma jelentősen kevesebb, mint a hagyományos, C stílusú programokban. En- 
nek ellenére a standard könyvtár még mindig a programozóra hárítja azt a feladatot, hogy 
elkerülje egy tároló memóriahatárainak átlépését. Ha például véletlenül valamilyen .x táro- 
lónak az x/x.size0-k 7] elemét próbáljuk meg elérni, akkor megjósolhatatlan — de általában 
rossz — események következhetnek be. Egy tartományellenőrzött vector használata (példá- 
ul a §3.7.1 pontban bemutatott Vec-é) néha segíthet ezen a problémán, sokkal általánosabb 
megoldást jelent azonban, ha a bejárókon keresztül történő minden hozzáférést ellenőr- 
zünk. 


Ahhoz, hogy ilyen szintű ellenőrzést érhessünk el anélkül, hogy jelentős terhet helyeznénk 
a programozó vállára, ellenőrzött bejárókra van szükségünk, és valamilyen kényelmes mód- 
szerre, amellyel ezeket a tárolókhoz kapcsolhatjuk. A Checked iter megvalósításához szük- 
ségünk van egy tárolóra és egy bejáróra, amely ebbe a tárolóba mutat. Ugyanúgy, mint a le- 
kötők (binder, §18.4.4.1) vagy a beszúró bejárók Cinserter, §19.2.4) esetében, most is külön 
függvényekkel segítjük az ellenőrzött bejárók létrehozását: 


templatexclass Cont, class Iter2 Checked iterScCont,Iter2 make checked(Contg c, Iter i) 


( 
return Checked iterSCont, Iter:(c,i; 


J 
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templatexclass Cont: Checked itercCont tybename Cont::iterator: make checked(Conik c) 


( 


return Checked itercZCont tybename Cont::iterator:(c,c.beginO); 


J 


Ezek a függvények sokat segítenek abban, hogy a típusokat a paraméterekből állapítsuk 
meg, és ne külön kelljen azokat megadni: 


void fvectorsint2k v, const vectorsint:£ vc) 


( 


typedef Checked itergvectorcint:, vectorsint:::iterator: CI; 
CI p1 - make checked(v,v.begin0-t39; 
CI p2 - make checked(v); // alapértelmezés szerint az első elemre mutat 


typedef Checked. itercconst vectorsint:, vectorsint:::const. iterator: CIC; 
CIC p3 - make checked(vc,vc.begin0--39; 
CIC pá - make checked(vc); 


const vectorsint2k vv — u; 
CIC p5 - make checked(v,uv.beginO); 


Alapértelmezés szerint a const tárolóknak minden bejárója is konstans, így az ezekhez tar- 
tozó Checked. iter osztályoknak is állandónak kell lenniük. A p5 bejáró arra mutat példát, 
hogyan hozhatunk létre const bejárót nem konstans tárolóból. 


Ez magyarázza azt is, hogy miért van szüksége a Checked iter típusnak két sablonparaméter- 
re: az egyik a tároló típusát adja meg, a másik a konstans/nem konstans különbséget fejezi ki. 


Ezen Checked iter típusok nevei elég hosszúak (és csúnyák), de ez nem számít, ha 
a bejárókat általánosított (generikus) algoritmusok paramétereként használjuk: 


templatecciass Iter: void mysort(lter first, Iter last); 


void Kvectorsint2g c) 
f 
try ( 
mysort(make checked(c), make checked(c,c.endO); 
) 
catch (out of bounds) ( 
cerrzá"hoppá: hiba a mysortO-banM "; 
abortO; 
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Ez pont egy olyan algoritmus, melynek első változataiban könnyen előfordulhat, hogy ki- 
lépünk a megengedett tartományból, így az ellenőrzött bejárók használata nagyon is indo- 
kolt. 


A Checked iter osztályt egy tárolóra hivatkozó mutatóval és egy olyan bejáróval ábrázolhat- 
juk, amely ebbe a tárolóba mutat: 


templatezclass Cont, class Iter - tybename Cont::iterator: 
class Checked iter : public iterator. traitszlter: ( 

Iter curr; // az aktuális pozícióra mutató bejáró 

Cont: c; // az aktuális tárolóra hivatkozó mutató 


Men 


b 
Az iterator. traits osztályból való származtatás az egyik lehetséges módszer a szükséges 
típusok (tybedef) meghatározásához. A másik egyszerű megoldás — az iterator osztályból 
való származtatás — ebben az esetben túlzott lenne (A reverse iterator esetében ezt a meg- 
oldást választottuk a §19.2.5 pontban). Ugyanúgy, ahogy egy bejárónak nem kell feltétlenül 
osztálynak lennie, egy osztályként meghatározott bejárónak sem kell feltétlenül az iterator 
osztály leszármazottjának lennie. 


A Checked iter osztály minden művelete egyértelmű: 


templatexclass Cont, class Iter - typename Cont::iterator: 
class Checked iter : public iterator. traitszlter: ( 


Ms 
bublic: 
void valid(lter p) const 
( 
if (c-cendOŐ -- p) return; 
for (ter pp - c-sbeginO; pp!-c-sendO; 44pp) if (pp —- p) return; 
throw out of boundsO; 
j 
friend bool operator-—(const Checked iterg i, const Checked iterg j) 
( 
return i.c——j.c dé i.CUTT——j.CUTT; 
j 


// nincs alapértelmezett kezdőérték-adó 


// alapértelmezett másoló konstruktor és értékadás használata 
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Checked iter(Contk x, Iter p) : c(k.x), curr(p) f valid(p9; ? 


reference type operator? const 

t 
if (curr--c-2endO) throw out of boundsO; 
return tcurr; 


) 


pointer. type operator-2) const 


J. 
t 


if (curr-—c-2endO) throw out of boundsO; 
return £ tcurr; 


fi 
Checked. iter operator4(Dist d) const // csak közvetlen elérésű bejárókhoz 
( 
if (c-xendO-currád 11 d£curr-c-2beginO) throw out of boundsO; 
return Checked iter(c,currtd); 
) 
reference type operator[ KDist d) const // csak közvetlen elérésű bejárókhoz 
( 
if (c-2endO-currszd 11 d£curr-c-2beginO) throw out of boundsO; 
return curr[d]; 
) 
Checked itergt oberator44O // prefix 44 
( 
if (curr -—— c-sendO) throw out of boundsO; 
FECUTT; 
return "this; 
) 
Checked iter operatortt(inD) // postfix 44 
fi 
í 
Checked iter tmp — "this; 
ta tthis; // prefix 43 által ellenőrzött 
return tmp; 
) 
Checked iterét operator--O // prefix -— 
( 


if (curr -- c-2beginO) throw out of boundsO; 
—Ccurr; 
return "this; 
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Checked iter operator--(int) // postfix — 
( 


Checked iter tmp — "this; 
-— this; // prefix -— által ellenőrzött 
return tmp; 


Jú 


difference tybe indexO const f return curr-c.beginO; ) // csak közvetlen elérés esetén 
Iter uncheckedO const f return curr; ? 


// a, -, £ stb. (§19.6/6D 
[4 


) 
Egy Checked. iter objektumot mindig egy bizonyos tároló egy bizonyos bejárójához kötünk. 
Egy alaposabb megvalósításban a validO függvénynek hatékonyabb változatát kell létre- 
hoznunk a közvetlen elérésű bejárókhoz (419.6I6D. Miután kezdőértéket adtunk 
a Checked iter objektumnak, minden műveletet ellenőrzünk, amely elmozdíthatja a bejárót, 
így mindig biztosak lehetünk abban, hogy az a tároló egy létező elemére mutat. Ha meg- 
próbálunk egy ilyen bejárót a tároló érvényes tartományán kívülre vinni, out of bounds ki- 
vételt kapunk: 


void f(listsstring:£ is) 


( 
int count — 0; 
try( 
Checked. iterz listsstring: 2 p(is,ls.beginO); 
while (true) ( 
tt; // előbb-utóbb a végére ér 
1rcoUNLt; 
J 
J 


catch(out of bounds5) ( 
cout 22 "Túllépés a tárolón " cz count 22 " próbálkozás után Ni"; 


J 


J 


A Checked. iter objektum pontosan tudja, melyik tárolóba mutat. Ez lehetővé teszi, hogy az 
olyan eseteket kezeljük, amikor egy tárolóba mutató bejáró érvénytelenné válik valamilyen 
művelet hatására (§16.3.8). Még így sem veszünk minden lehetőséget figyelembe, tehát ha 
az összes hibalehetőségre fel akarunk készülni, akkor egy másik, bonyolultabb bejárót kell 
készítenünk (ásd §19.6[7D. 
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Figyeljük meg, hogy az utótagként használt --4 operátor megvalósításához szükség van egy 
ideiglenes tárolóelemre, míg az előtag-formánál erre nincs szükség. Ezért bejárók esetében 


mindig érdemes a pt forma helyett a --tb alakot használni, ha az ellenkezőjére nincs kü- 
lönösebb okunk. 


Mivel a Checked iter egy tárolóra hivatkozó mutatót tárol, közvetlenül nem használható 
a beépített tömbök kezeléséhez. Ha mégis ilyesmire van szükségünk, a c array típust 
(§17.5.4) használhatjuk. 


Ahhoz, hogy az ellenőrzött bejárók megvalósítását teljessé tegyük, használatukat egyszerű- 
vé kell tennünk. Két megközelítéssel próbálkozhatunk: 


1. Meghatározunk egy ellenőrzött tároló típust, amely ugyanúgy viselkedik, mint 
az átlagos tárolók, attól eltekintve, hogy kevesebb konstruktor áll benne rendel- 
kezésünkre és a beginO, endO stb. eljárások mind Check iter objektumot adnak 
vissza a szokásos bejárók helyett. 

2. Készítünk egy kezelőosztályt, amelynek valamilyen tárolóval adhatunk kezdőér- 


téket, és amely ehhez a tárolóhoz a későbbiekben csak ellenőrzött hozzáférése- 
ket engedélyez (419.6[8D. 


Az alábbi sablon egy ellenőrzött bejárót köt egy tárolóhoz: 


templatexclass C2 class Checked : public C f 
bublic: 
explicit Checked(size tn) :C(n) ( ) 
CheckedO :C0 f ) 


typedef Checked, iterzC: iterator; 
typedef Checked. iterSC, C::const iterator: const iterator; 


iterator beginO ( return iteratorC"this, C::beginO); ) 
iterator endO f return iteratorCthis, C::endO); ) 


const iterator beginO const f return const iteratorC"this, C::beginO 9; ) 
const iterator endŐ const f return const iterator("this, C::endO); ? 


reference type operatorl (size t n) f return Checked iterZCez(Ctthis)[n]; ) 


ck baseO f return static casiZCko("this); ) // rögzítés az alaptárolóhoz 
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Ezután használhatjuk az alábbi programrészletet: 


Checked£ vectorcint: 5 vec(10)9; 
Checkedz listdouble: : list; 


void JO 

( 
int v1 — vec[5]; // rendben 
int v2 - vec[15]; // out of bounds kivételt vált ki 
Aaa 


Ist.push back(v29); 
mysort(vec.beginO), vec.endO; 


copy(vec.beginO, vec.endO, lst.beginO; 
? 


J 
A látszólag felesleges base0 függvény szerepe az, hogy a CheckedO felületét a tárolók 
kezelőinek (handle) felületéhez igazítsa, ezek ugyanis általában nem tesznek lehetővé au- 
tomatikus konverziókat. 


Ha a tároló mérete megváltozik, bejárói érvénytelenné válnak. Ez történik a Checked iter 
objektumokkal is. Ebben az esetben a Checked iter-nek a következő kódrészlettel adha- 


tunk új kezdőértéket: 


void g(vectorsint:£ vi) 


( 
Checked. itersint: p(vi,vi.beginO ); 
1 as 
int i — p.indexO; // aktuális pozíció lekérése 
vi.resize(100); // p érvénytelen lesz 
p - Checked itersintx(vi, vi.begin ri); // az aktuális pozíció visszaállítása 


A régi , aktuális pozíció" érvénytelenné válik, ezért szükségünk van az indexO függvényre, 
amely egy Checked iter tárolására és visszaállítására használható. 


19.3.1. Kivételek, tárolók és algoritmusok 


Könnyen úgy tűnhet, hogy a szabványos algoritmusok és az ellenőrzött bejárók együttes 
használata olyan felesleges, mint az öv és a nadrágtartó együttes viselése: mindkettő önma- 
gában is megvéd minket a , balesetektől". Ennek ellenére a tapasztalat azt mutatja, hogy sok 
ember és sok alkalmazás számára indokolt ilyen szintű paranoia, különösen akkor, ha egy 
gyakran változó programot sokan használnak rendszeresen. 
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A futási idejű ellenőrzések használatának egyik módja, hogy csak a tesztelés idejére hagy- 
juk azokat programunkban. Tehát ezek az ellenőrzések eltűnnek a programból, mielőtt az 
, éles" körülmények közé kerülne. Ez az eljárás ahhoz hasonlítható, mint amikor a mentő- 
mellényt addig hordjuk, amíg partközelben pancsolunk, és levesszük, amikor a nyílt 
tengerre merészkedünk. Ugyanakkor igaz, hogy a futási idejű ellenőrzések jelentős 
mennyiségű időt és memóriát igényelhetnek, így folyamatosan ilyen felügyeletet biztosíta- 
ni nem lehet valós elvárás. Jelentéktelen haszon érdekében optimalizálni mindig felesleges, 
tehát mielőtt véglegesen törlünk bizonyos ellenőrzéseket, próbáljuk ki, hogy jelentős mér- 
tékű teljesítményjavulást érünk-e el így. Ahhoz, hogy a programozó tényleg próbálkozhas- 
son ilyesmivel, könnyűvé kell tennünk számára a futási idejű ellenőrzések eltávolítását 
(424.3.7.1D. Ha elvégeztük a szükséges méréseket, a futási idejű ellenőrzéseket a létfontos- 
ságú — és remélhetőleg a legalaposabban tesztelt — helyekről törölhetjük, míg máshol az el- 
lenőrzést egy viszonylag olcsó biztosításnak tekinthetjük. 


A Checked iter használata számtalan hibára felhívhatja figyelmünket, de nem sokat segít 
abban, hogy ezeket a hibákat kijavítsuk. A programozók ritkán írnak olyan programokat, 
amelyek minden lehetőségre felkészülnek és ellenőriznek minden műveletet, amely kivé- 
telt okozhat (--x, --, t, /], 2 és 5. Így két nyilvánvaló stratégia közül választhatunk: 


1. A kivételeket keletkezési helyük közelében kapjuk el, így a kivételkezelő meg- 
írója pontosabban megállapíthatja a hiba okát és hatékony ellenlépéseket tehet. 

2. A kivételeket a programban viszonylag magas szinten kapjuk el, az eddigi szá- 
mításoknak egy jelentős részét eldobjuk, és minden adatszerkezetet gyanúsnak 
minősítünk, amelybe írás történt a hibát kiváltó számítás közben. (Lehet, hogy 
ilyen adatszerkezetek nincsenek is, esetleg könnyen kizárhatók a hibaforrások 
köréből.) 


Felelőtlenség elkapni egy kivételt, amelyről azt sem tudjuk, hogy a program mely részén 
keletkezett, és továbblépni azzal a feltételezéssel, hogy egyetlen adatszerkezetünk sem 
került nemkívánatos állapotba, hacsak nincs egy további hibakezelő, amely az ezután ke- 
letkező hibákat feldolgozza. Egy egyszerű példa az ilyen helyzetre, amikor az eredmények 
továbbadása előtt egy végső ellenőrzést végzünk (akár számítógépről, akár emberi munka- 
végzésről van szó). Ilyenkor egyszerűbb és olcsóbb ártatlanul továbbhaladni, minthogy 
alacsony szinten minden hibalehetőséget megvizsgáljunk. Ezzel egyben arra is példát 
mutattunk, hogy a többszintű hibakezelés (§14.9) hogyan teszi lehetővé a programok 


egyszerűsítését. 
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19.4. Memóriafoglalók 


A memóriafoglalók (allokátorok, allocator) szerepe az, hogy a fizikai memória kezelésének 
gondját levegyék azon algoritmusok és tárolók készítőinek válláról, melyek számára memó- 
riát kell lefoglalnunk. A memóriafoglalók szabványos felületet adnak a memóriaterületek 
lefoglalásához és felszabadításához, valamint szabványos neveket adnak azoknak a típu- 
soknak, melyeket mutatóként vagy referenciaként használhatunk. A bejáróhoz hasonlóan 
a memóriafoglaló fogalma is tisztán elvont, így mindent memóriafoglalónak nevezünk, ami 
memóriafoglalóként viselkedik. 


A standard könyvtár egy szabványos memóriafoglalót biztosít, amely a legtöbb felhasználó 
számára megfelelő, de ha szükség van rá, a programozók maguk is létrehozhatnak egyéni 
változatokat, melyekkel a memóriát más szerkezetűnek tüntethetik fel. Készíthetünk példá- 


ul olyan memóriafoglalót, amely osztott memóriát használ, szemétgyűjtő algoritmust valósít 
meg, előre lefoglalt memóriaszeletből hozza létre az objektumokat (419.4.2) és így tovább. 


A szabványos tárolók és algoritmusok a működésükhöz szükséges memóriát mindig me- 
móriafoglaló segítségével foglalják le és érik el. Így ha új memóriafoglalót készítünk, a szab- 
ványos tárolókat is felruházzuk azzal a képességgel, hogy a memóriát megváltozott szem- 
szögből lássák. 


19.4.1. A szabványos memóriafoglaló 


A szabványos allocator sablon a cmemory? fejállományban található és a memóriafoglalást 
a newO operátor (46.2.6) segítségével végzi. Alapértelmezés szerint mindegyik szabványos 
tároló ezt használja: 


template cclass T- class std::allocator f 
bublic: 

typedef T value type; 

typedef size t size type; 

typedef ptrdijff t difference type; 


typedef T" pointer; 
typedef const T" const pointer; 


typedef Ik reference; 
typedef const Ik const reference; 


ointer address(reference r) const f return £r; ) 
fi 7 J 
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const pointer address(const reference r) const ( return £r; ) 


allocatorÓ throwO; 
template Sclass U: allocatorcconst allocatorSU:£ ) throwO; 
-allocatorÓ throwO; 


pointer allocate(size type n, allocatorgvoid:::const pointer hint - 0); // hely n darab 
// Ts számára 
void deallocate(pointer p, size type n); // n darab TS helyének felszabadítása, 


// megsemmisítés nélkül 


void construct(bpointer p, const Tk val) f neu(p) KvaD; ) // ?p feltöltése val-lal 
void destroy(pointer p) ( b-2-TÖ; ) // "p megsemmisítése a hely felszabadítása 
// nélkül 


size type max sizeO const throwO); 


template class U2 

struct rebind f typedef allocatorSU: other; );  // valójában typedef allocatorSU: other 
sz 
templatexcilass T- bool operator-—(const allocatorzT:k, const allocatorST:£ ) throwO; 
templatecxclass T2 bool operator!1—(const allocatorzT:£, const allocatorkT:£) throwO; 


Az allocatern) művelettel n objektum számára foglalhatunk helyet, párja pedig 
a deallocate(p,n), mellyel felszabadíthatjuk az így lefoglalt területet. Figyeljük meg, hogy 
a deallocate0 függvénynek is átadjuk az n paramétert. Ezzel a megoldással közel optimá- 
lis memóriafoglalókat készíthetünk, amelyek csak a feltétlenül szükséges információkat tá- 
rolják a lefoglalt területről. Másrészt viszont ezek a memóriafoglalók megkövetelik, hogy 
a programozó mindig a megfelelő n értéket adja meg a deallocate0 hívásakor. Megjegyzen- 
dő, hogy a deallocate0 különbözik az oberator deleteO-től, amennyiben mutató paraméte- 
re nem lehet nulla. 


Az alapértelmezett allocator a new(size t) operátort használja a memória lefoglalásához és 
a delete(void?") műveletet a felszabadításához. Ebből következik, hogy szükség lehet 
a new handlerŐ meghívására és a std::bad alloc kivétel kiváltására, ha elfogyott a memó- 


ria (§6.2.6.2). 


Jegyezzük meg, hogy az allocate0 függvénynek nem kell feltétlenül meghívnia egy ala- 
csonyszintű memóriafoglalót. Gyakran jobb megoldást jelent egy memóriafoglaló számára, 
ha ő maga tartja nyilván a kiosztásra kész, szabad memóriaszeleteket, és ezeket minimális 
időveszteséggel adja ki (419.4.2). 


A nem kötelező hint paraméter az allocate0 függvényben mindig az adott megvalósítástól 
függ. Mindenképpen arra szolgál, hogy segítse a memóriafoglalót azokban a rendszerek- 
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ben, ahol fontos a lokalitás (vagyis az adott rendszerhez igazodás). Egy memóriafoglalótól 
például elvárhatjuk, hogy egy lapozós rendszerben az összefüggő objektumoknak azonos 


lapon foglaljon helyet. A hint paraméter típusa pointer, az alábbi erőteljesen egyszerűsített 
specializációnak megfelelően: 


template £2 class allocatorzvoid: f 
bublic: 
typedef void? pointer; 
typedef const void?" const pointer; 
// megj.: nincs referencia 
typedef void value type; 
template class U: 
struct rebind f typedef allocatorSU: other; ?; // valójában typedef allocatorSU: other 


Az allocatorgvoid2::pointer típus általános mutatótípusként szolgál és minden szabványos 
memóriafoglaló esetében a const void" típusnak felel meg. 


Ha a memóriafoglaló dokumentációja mást nem mond, a programozó két lehetőség közül 
választhat az allocate0 függvény használatakor: 


1. Nem adja meg a hint paramétert. 
2. A hint paraméterben egy olyan objektumra hivatkozó mutatót ad meg, amelyet 
gyakran használ majd az új objektummal együtt. Egy sorozatban például meg- 


adhatjuk az előző elem címét. 


A memóriafoglalók arra szolgálnak, hogy megkíméljék a tárolók készítőit a fizikai memória 
közvetlen kezelésétől. Példaképpen vizsgáljuk meg, hogy egy vector megvalósításában ho- 
gyan használjuk a memóriát: 


template cclass T, class A - allocatorST: : class vector f 
bublic: 
typedef typename A::pointer iterator; 
Ms 
brivate: 
A alloc; // memóriafoglaló objektum 
iterator u; // mutató az elemekre 


V/dss 


bublic: 
explicit vectorcsize type n, const Tk val - TO, const A£ a - 40) 
: allocC(a) 
í 
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v — alloc.allocate(n); 
forditerator p -— v; pZvtn; 44p) alloc.construct(p, vaD; 


dea 
fi 
void reserve(size type n) 
( 
if (nc-capacityO) return; 
iterator p — alloc.allocate(n); 
iterator g — u; 
while (gZvtsizeO) f // létező elemek másolása 
alloc.construct(bt4, "90; 
alloc.destroy(g43); 
f 
alloc.deallocate(v, capacityO 9; // régi hely felszabadítása 
v - p-sizeO; 
Ú 4 
fi 
VS 


VA 


A memóriafoglalók műveleteit a bointerés reference typedef-ek segítségével fejezzük ki, így 
megadjuk a programozónak azt a lehetőséget, hogy más típusokat használjon a memória 
eléréséhez. Ezt általában nagyon nehéz megoldani. A C-- nyelv segítségével például nincs 
lehetőségünk arra, hogy egy tökéletes hivatkozástípust határozzunk meg. A nyelv és 
a könyvtárak alkotói viszont ezeket a typedef-eket olyan típusok létrehozásához használhat- 
ják, amelyeket egy átlagos felhasználó nem tudna elkészíteni. Példaként egy olyan memó- 
riafoglalót említhetünk, amely állandó adatterület elérésére szolgál, de gondolhatunk egy 
, nagy" mutatóra is, amellyel a memóriának azt a területét is elérhetjük, amit a szokásos (ál- 
talában 32 bites) mutatók már nem képesek megcímezni. 


Egy átlagos felhasználó a memóriafoglalónak egyedi célra megadhat a szokásostól eltérő 
mutatótípust is. Ugyanezt nem tehetjük meg referenciákkal, de ez a korlátozás kísérletezés- 
nél vagy egyedi rendszerekben nem okoz nagy gondot. 


Memóriafoglalót azért hozunk létre, hogy könnyen kezelhessünk olyan objektumokat, me- 
lyeknek típusát a memóriafoglaló sablonparamétereként adtuk meg. A legtöbb tároló meg- 
valósításában azonban szükség van más típusú objektumok létrehozására is. Például a list 
megvalósításához szükség van Link objektumok létrehozására. Az ilyen Link jellegű objek- 
tumokat a megfelelő /ist osztály memóriafoglalójával hozzuk létre. 
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A furcsa rebind típus arra szolgál, hogy memóriafoglaló képes legyen bármilyen típusú ob- 
jektum helyének lefoglalására: 


typedef typename A::template rebindzLink:::other Link alloc; // "sablon", lásd §C.13.6 


Ha A egy allocator, akkor a rebindcLink:::other típus-meghatározás jelentése 
allocatorsltink?, tehát a fenti typedefegy közvetett megfogalmazása az alábbinak: 


typedef allocatorslLink: Link alloc; 


A közvetett megfogalmazás azonban megkímél minket attól, hogy az allocator kulcsszót 
közvetlenül használjuk. A Link alloc típust csak az A sablonparaméteren keresztül határoz- 
zuk meg. Például: 

template class T, class A - allocatorsT: : class list f 

brivate: 


class Tink €/E ... "73; 


typedef typename A::rebindzLink2::other Link alloc; — // allocatorzLink: 


Link alloc a; // "link" memóriafoglaló 

A alloc; // "list" memóriafoglaló 

MESE 

bublic: 

typedef typename A::pointer iterator; 

17 aa: 

iterator insert(iterator pos, const Ik x ) 

t 
Link alloc::bointer p - a.allocate( 19; // egy Link megszerzése 
Mas 

j 

17 a 


Mivel a Link a list osztály tagja, paramétere egy memóriafoglaló. Ennek következében a kü- 
lönböző memóriafoglalókkal rendelkező listák Link objektumai különböző típusúak, 
ugyanúgy, ahogy maguk a listák is különböznek (417.3.39. 
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19.4.2. Felhasználói memóriafoglalók 

A tároló készítőjének gyakran van szüksége arra, hogy egyesével hozzon létre (allocate0) 
vagy semmisítsen meg (deallocateO) objektumokat. Ha az allocate0 függvényt meggondo- 
latlanul készítjük el, nagyon sokszor kell meghívnunk a new operátort, pedig a new operá- 
tor ilyen használatra gyakran kis hatékonyságú. A felhasználói memóriafoglalók példája- 
ként az alábbiakban olyan módszerrel élünk, mellyel egy , készletet" hozunk létre, amely 
rögzített méretű memóriaszeleteket tárol. A memóriafoglaló ennek felhasználásával hatéko- 
nyabban hajtja végre az allocate0 eljárást, mint a hagyományos (bár általánosabb) newO 
operátor. 


Véletlenül én már korábban is létrehoztam egy ilyen készletes memóriafoglalót, amely kö- 
rülbelül azt csinálja, amire most szükségünk van, de nem a megfelelő felületet nyújtja Chi- 
szen évekkel azelőtt készült, hogy a memóriafoglalók ötlete megszületett volna). Ez a Pool 
osztály meghatározza a rögzített méretű elemek készletét, amelyből a programozó gyorsan 
foglalhat le területeket és gyorsan fel is szabadíthatja azokat. Ez egy alacsonyszintű típus, 
amely közvetlenül a memóriát kezeli és az igazítási (alignmen09) problémákkal is foglalkozik: 


class Pool f 
struct Link f( Link?" next; ?; 


struct Chunk ( 


enum f size - 8t1024-16 ?; // valamivel kevesebb 8K-nál, így egy 
// "Chunk" belefér 8K-ba 

char memlsizel; // először a lefoglalandó terület az igazítás 
// miatt 


Chunk? next; 


Fi 
Chunk? chunks; 


const unsigned int esize; 
Link?" head; 


Pool(Poolk ); // másolásvédelem 
void operator—-(Pool£ ); // másolásvédelem 
void growO; // a készlet növelése 
bublic: 
Pookunsigned int n); // n az elemek mérete 
-PoolO; 
void? allocO; // hely foglalása egy elem számára 


void free(void? b); // elem visszahelyezése a készletbe 


); 
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inline void? Pool::allocO 
( 
if (head--0) growO); 
Link" p - head; // az első elem visszaadása 
head - p-2next; 
return p; 


j 


inline void Pool::free(void? b) 


( 
Link? p - static castzlinktx(b); 
bP-2next - head; // b visszahelyezése első elemként 
head - p; 


j; 


Pool::Poolk(unsigned int sz) 

: esizer(szssizeofttink)"sizeolttink):sz) 
( 

head — 0; 

chunks — 0; 


j 


Pool::-PoolO // minden tchunk! felszabadítása 
t 
Chunk: n - chunks; 
while (n) (f 
Chunk? p - n; 
n - n-2next; 
delete bp; 
) 


j 
void Pool::growO — // hely foglalása új chunk! számára, melyet tesize"! méretű elemek 
// láncolt listájaként rendezünk 
( 
Chunk:" n - new Chunk; 
n-2next - chunks; 
chunks — n; 


const int nelem - Chunk::size/esize; 
char? start -— n-:2mem; 
char? last — gstart((nelem-1) "esizel; 


for (char? p - start; pzlast; p4-esize) 

reinterpret castslinktr(p)-:next - reinterpret castslinktr-(ptesize); 
reinterpret castzltinktr(lasD--next - O; 
head - reinterpret castsZink?":(star0); 
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A valós életben zajló munka szemléltetésére a Pool osztályt változatlan formában használ- 
juk fel az új memóriafoglaló megvalósításához, nem csak átírjuk, hogy a nekünk megfelelő 
felületet nyújtsa. A készletes memóriafoglaló célja, hogy objektumaink egyesével történő 
létrehozása és megsemmisítése gyors legyen. A Pool osztály mindezt biztosítja. A megvaló- 
sítást azzal kell még kiegészítenünk, hogy egyszerre tetszőleges számú, illetve ( a rebindO 
igényeinek megfelelően) tetszőleges méretű objektumokat is létrehozhassunk. Ezt a két 
problémát feladatnak hagyjuk (419.6[9]). 


A Pool osztály felhasználásával a Pool alloc megvalósítása már egyszerű: 


template cclass T- class Pool alloc f 


brivate: 

static Pool mem; // elemkészlet sizeof( 1) mérettel 
bublic: 

// mint a szabványos allocator (§19.4.1 
3; 


template Sclass T- Pool Pool allocszT:::mem(sizeof(); 
template Sclass T- Pool allocsT:::Pool allocO f ? 


template cclass T- 
T" Pool allocsT:::allocatecsize type n, void?" - 0) 
f 
if (n —— 1) return static castZT"x(mem.allocO); 
ZAK 
J 


template Sclass T- 
void Pool allocsT:::deallocate(pointer p, size type n) 


( 
if(n -- 1) ( 
mem free(p); 
return; 
, 
VÁROS 
J 


A memóriafoglalót ezután már a megszokott formában használhatjuk: 


vectork int,Pool allocsint: 5 u; 
mapsstring, number,Pool allocs pairsconst string,number: 5 5 m; 


// ugyanúgy mint szoktuk 


vectorsint: v2 — u; // hiba: különböző memóriafoglaló-baraméterek 
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A Pool Alloc megvalósításához statikus Pool objektumot használunk. Azért döntöttem így, 
mert a standard könyvtár a memóriafoglalókra egy korlátozást kényszerít, mégpedig azzal, 
hogy a szabványos tárolók megvalósításának megengedi, hogy minden objektumot egyen- 
értékűnek tekintsenek, amelynek típusa az adott tároló memóriafoglalója. Ez valójában 
igen jelentős hatékonysági előnyöket jelent: ennek a korlátozásnak köszönhetően a Link 
objektumok memóriafoglalóinak például nem kell külön memóriaterületet félretennünk 
(annak ellenére, hogy a Link osztály általában paraméterként egy memóriafoglalót kap 
ahhoz a tárolóhoz, amelyben szerepel, §19.4.1). Egy másik előny, hogy azokban a művele- 
tekben, ahol két sorozat elemeit kell elérnünk (például a swapO függvényben), nem kell 
megvizsgálnunk, hogy a használt elemek ugyanolyan memóriafoglalókkal rendelkeznek-e. 
A hátrány, hogy a korlátozás következtében az ilyen memóriafoglalók nem használhatnak 
objektumszintű adatokat. 


Mielőtt ilyen optimalizációt használnánk, gondoljuk végig, hogy szükség van-e rá. Én remé- 
lem, hogy az alapértelmezett allocator legtöbb megvalósításában elvégzik ezt a klasszikus 
C4-4 optimalizációt, így megkímélnek minket ettől a problémától. 


19.4.3. Általánosított memóriafoglalók 

Az allocator valójában nem más, mint annak az ötletnek az egyszerűsített és optimalizált vál- 
tozata, miszerint egy tárolónak egy sablonparaméteren keresztül adjuk meg az információ- 
kat (413.4.1., §16.2.3). Logikus elvárás például, hogy a tároló minden elemének helyét a tá- 
roló memóriafoglalójával foglaljuk le. Ha azonban ilyenkor lehetővé tesszük, hogy két 
ugyanolyan típusú /Zist tárolónak különböző memóriafoglalója legyen, akkor a spliceO 
(§17.2.2.1) nem valósítható meg egyszerű átláncolással, hanem szabályos másolást kell meg- 
határoznunk, mert védekeznünk kell azon (ritka) esetek ellen, amikor a két listában a me- 
móriafoglalók nem azonosak, annak ellenére, hogy típusuk megegyezik. Hasonló probléma, 
hogy ha a memóriafoglalók tökéletesen általánosak, akkor a rebindO eljárásnak (amely tet- 
szőleges típusú elemek létrehozását teszi lehetővé a memóriafoglaló számára) sokkal bo- 
nyolultabbnak kell lennie. Ezért a , normális" memóriafoglalókról azt feltételezzük, hogy 
nem tárolnak objektumszintű adatokat, az algoritmusok pedig kihasználhatják ezt. 


Meglepő módon ez a drákói korlátozás az objektumszintű információkra nézve nem túlsá- 
gosan veszélyes a memóriafoglalók esetében. A legtöbb memóriafoglalónak nincs is szük- 
sége objektumszintű adatokra, sőt ilyen adatok nélkül még gyorsabbak is lehetnek, ráadá- 
sul a memóriafoglalók azért tudnak adatokat tárolni, a memóriafoglaló-típusok szintjén. 
Ha külön adatelemekre van szükség, különböző memóriafoglaló-típusokat használhatunk: 
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templatecxciass T, class D: class My alloc ( // T memóriafoglalóját D használatával 
// hozzuk létre 
D d; // a My. allocsT;D: számára szükséges adatok 
sz 
j; 


typedef My. allocsint, Persistent info: Persistent; 
typedef My. alloczint Shared info: Shared; 
typedef My. alloczint, Default infoz Default; 


listzint, Persistent2 Ist1; 
listsint, Shared: Ist2; 
listzint Default: Ist3; 


Az Ist1, az Ist2 és az ist3 listák különböző típusúak, így ha közülük kettőt akarunk felhasz- 
nálni valamilyen műveletben, akkor általános algoritmusokat kell használnunk (18.fejezet), 
nem pedig specializált lista műveleteket (417.2.2.19. Ebből következik, hogy az átláncolás 
helyett másolást kell használnunk, így a különböző memóriafoglalók használata nem okoz 
problémát. 


Az objektumszintű adatokra vonatkozó korlátozásokra a memóriafoglalókban azért van 
szükség, mert így tudjuk kielégíteni a standard könyvtár szigorú hatékonysági követelmé- 
nyeit, mind futási idő, mind tárhasználat szempontjából. Egy lista memóriafoglalója példá- 
ul nem foglal jelentősen több memóriát a szükségesnél, de ha minden listaelemnél jelent- 
kezne egy kis , felesleg", akkor ez jelentős veszteséget okozna. 


Gondoljuk végig, hogyan használhatnánk a memóriafoglalókat akkor, ha a standard könyv- 
tár hatékonysági követelményeitől eltekintenénk. Ez a helyzet olyan nem szabványos 
könyvtár esetében fordulhat elő, melyben nem volt fontos tervezési szempont a nagy haté- 
konyság az adatszerkezetek és típusok létrehozásakor, vagy akár a standard könyvtár bizo- 
nyos egyedi célú megvalósításaiban. Ilyenkor a memóriafoglaló felhasználható olyan jelle- 
gű információk tárolására is, melyek általában általános bázisosztályokban kapnak helyet 
(§16.2.2). Készíthetünk például olyan memóriafoglalókat, melyek választ tudnak adni arra 
a kérdésre, hogy az objektumok hol kaptak helyet, kínálhatnak olyan információkat, me- 
lyek az objektumok elrendezésére vonatkoznak, vagy megkérdezhetjük tőlük, hogy egy 
adott elem benne van-e a tárolóban. Segítségükkel elkészíthető egy olyan tárolófelügyelő 
is, amely gyorsítótárként szolgál a háttértárhoz vagy kapcsolatokat biztosít a tároló és más 
objektumok között és így tovább. 


Ezzel a módszerrel tehát tetszőleges szolgáltatásokat biztosíthatunk a szokásos 
tárolóműveletek hátterében. Ennek ellenére érdemes különbséget tennünk az adatok táro- 
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lásának és az adatok felhasználásának feladatai között. Ez utóbbi nem tartozik egy általáno- 
sított memóriafoglaló hatáskörébe, így inkább egy külön sablonparaméter segítségével illik 
megvalósítanunk. 


19.4.4. Előkészítetlen memória 


A szabványos allocator mellett a Cmemory? fejállományban találhatunk néhány olyan függ- 
vényt is, melyek az előkészítetlen (értékkel nem feltöltötb memória problémáival foglal- 
koznak. Azt a veszélyes, de gyakran nagyon fontos lehetőséget biztosítják, hogy a Ttípus- 
névvel hivatkozhatunk egy olyan memóriaterületre, amely elég nagy egy Ttípusú objektum 
tárolására, de nem teljesen szabályosan létrehozott 7 objektumot tartalmaz. 


A könyvtárban három függvényt találunk, mellyel előkészítetlen területre értékeket 
másolhatunk: 


template class In, class For: 
For uninitialized copydn first, In last, For res) // másolás res-be 


( 


typedef typename iterator. traitsZFor:::value type V; 


while (first !- las) 
new (static castZvoid"(£?"rest4)) VC firsta4); // létrehozás res-ben (§10.4.11) 
return res; 


j 


template class For, class T- 
void uninitialized fill(For first, For last, const TX val) //másolás (first, last)-ba 


( 


typedef typename iterator. traitsZFor:::value type V; 


while (first !- las9) new (static castZvoid"(k?first44)) V(vaD; 7 létrehozás first-ben 


J 


template cclass For, class Size, class T- 
void uninitialized fill n(For first, Size n, const Ik val) //másolás (first firsta:n)-be 


( 


typedef typename iterator. traitsZFor:::value type V; 


while (n--) new (static castgvoid"2(£ "first4-4)) V(vaD; // létrehozás first-ben 


j 


Ezek a függvények elsősorban tárolók és algoritmusok készítésénél hasznosak. A reserveO 
és a resizeO (416.3.8) például legkönnyebben ezen függvények felhasználásával valósítha- 
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tó meg (§419.6[10]. Igen nagy probléma, ha egy ilyen kezdőértékkel nem rendelkező objek- 
tum valahogy kiszabadul a tároló belső megvalósításából és átlagos felhasználók kezébe 
kerül (lásd még SE.4.4). 


Az algoritmusoknak gyakran van szükségük ideiglenes tárterületre feladataik helyes végre- 
hajtásához. Ezeket a területeket gyakran érdemes egyetlen művelettel lefoglalni, annak el- 
lenére, hogy értékkel feltölteni csak akkor fogjuk azokat, amikor ténylegesen szükség lesz 
rájuk. Ezért a könyvtár tartalmaz egy függvénypárt, mellyel előkészítetlen memóriaterületet 
foglalhatunk le, illetve szabadíthatunk fel: 


template cclass T2 pairzT" ptrdiff t- get temporary bujffer(ptrdiff WV; 7 lefoglalás 
// kezdeti értékadás 
// nélkül 

template Sclass T- void return temporary buffer(T?); // felszabadítás 
// megsemmisítés 
// nélkül 


A get temporary bujfferzx:(n) művelet megpróbál helyet foglalni z vagy több X típusú ob- 


jektum számára. Ha ez sikerül, akkor az első kezdőérték nélküli objektumra hivatkozó muta- 
tót és a lefoglalt területen elférő, X típusú objektumok számát adja vissza. Ha nincs elég me- 
mória, a visszaadott pár második (second) tagja nulla lesz. Az ötlet az, hogy a rendszer a gyors 
helyfoglalás érdekében rögzített méretű átmeneti tárat tart készenlétben. Ennek következté- 
ben előfordulhat, hogy n objektum számára igénylünk területet, de az átmeneti tárban ennél 
több is elfér. A gond az, hogy az is elképzelhető, hogy kevesebb területet kapunk az igényelt- 
nél, így a get temporary bujfferO felhasználási módja az, hogy kellően nagy tárat igénylünk, 
aztán ebből annyit használunk fel, amennyit megkaptunk. A get temporary bufferO által le- 
foglalt területet fel kell szabadítanunk a return temporary bufferO függvény segítségével. 
Ugyanúgy, ahogy a get temporary bufferOŐ a konstruktor meghívása nélkül foglal le területet, 
a return temporary bufferO a destruktor meghívása nélkül szabadít fel. Mivel 
a get temporary bufferO alacsonyszintű művelet és kifejezetten ideiglenes tárak lefoglalásá- 
ra szolgál, nem használhatjuk a new vagy az allocator::allocate0 helyett, hosszabb életű ob- 


jektumok létrehozására. 


Azok a szabványos algoritmusok, melyek egy sorozatba írnak, feltételezik, hogy a sorozat 
elemei korábban már kaptak kezdőértéket. Tehát az algoritmusok az íráshoz egyszerű 
értékadást használnak és nem másoló konstruktort. Ennek következtében viszont nem 
használhatunk előkészítetlen területet egy algoritmus kimenete céljára. Ez sokszor igen kel- 
lemetlen, mert az egyszerű értékadás jóval , költségesebb", mint a kezdeti, ráadásul nem is 
érdekel minket, milyen értékeket fogunk felülírni (ha érdekelne, nem írnánk felül). A meg- 
oldást a raw storage iterator jelenti, amely szintén a cmemory? fejállományban található 
és egyszerű helyett kezdeti értékadást végez: 
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template class Out, class T- 
class raw storage iterator : public iteratorcoutput iterator. tag, void, void, void, void: f 
Out p; 
bublic: 
explicit raw storage iterator(Out pp) : P(pp) t ; 
raw storage iteratork operator? f return "this; ) 
raw storage iteratork operator—-(const Ik val) ( 
Tt pp - £"p; 
neu(pp) KvaD;  /7 val pp-be helyezése (§10.4.11) 
return "this; 
j 
raw storage iteratordt operatortt0 f4t1p; return "this; ) 
raw storage iterator operatort4(int) ( 
raw storage iterator t - "this; 
HED; 


return t; 


Például készíthetünk egy sablon függvényt, amely egy vector elemeit egy átmeneti tárba 
másolja: 


templatecxciass T, class Az T" temporary dup(vectorsT,A:£ v) 
( 
bairzT" ptrdiff t- p - get temporary bujfferzTex(v.sizeO); 
if (p.second £ v.sizeO) ( // ellenőrizzük, hogy elég volt-e az elérhető memória 
if (p first !- 0) return temporary buffer(p.firsD; 
return 0; 


) 
copy(v.beginO, v.endO, raw storage iteratorcT", Tx(p.firsD); 
return p. first; 


Ha a get temporary bufferŐ helyett a new operátort használtuk volna, az átmeneti tár kez- 
deti feltöltésére sor került volna. Mivel kikerültük az előkészítést, a raw storage iterator 
osztályra van szükségünk a nem feltöltött terület kezeléséhez. Ebben a példában 
a temporary dumpO függvény meghívójának feladata marad, hogy meghívja 
a return temporary bujfferŐ eljárást a visszaadott mutatóra. 


19. Bejárók és memóriafoglalók 771 


19.4.5. Dinamikus memória 


A cnew? fejállományban olyan lehetőségek szerepelnek, melyekkel a new és delete operá- 
tort valósíthatjuk meg: 


class bad alloc : public exception £ /? ... "/ ); 


struct nothrow t (7; 
extern const nothrow t nothrow; // kivételt ki nem váltó memóriafoglaló 


typedef void ("new handler)O; 
new handler set new handler(new handler new p) throwO; 


void? operator neu(size b) throuw(bad alloc); 
void operator delete(void") throwO; 


void? operator neu(size t, const nothrow it£) throwO); 
void operator delete(void", const nothrow t£) throwO); 


void? operator neul (size 1) throw(bad alloc); 
void operator deletel void?) throwO; 


void? operator neul k(size t, const nothrow I£) throwO; 
void operator deletel void?, const nothrow t£) throwO); 


void? operator new (size t, void" p) throwOfreturnp;) // elhelyezés (§10.4.11) 
void operator delete (void? p, void") throuO f ) //nem csinál semmit 


void? operator neul I(size t, void? p) throuO f( return p; ) 
void operator deletel void? p, void") throu0 f ) //nem csinál semmit 


Egy üres kivétel-specifikációval (§14.6) definiált oberator newO vagy operator neul JO nem 
jelezheti a memória elfogyását az szd::bad alloc kivétel kiváltásával. Ehelyett, ha sikertelen 
a helyfoglalás, 0 értéket adnak vissza. A new kifejezés (46.2.6.2) az üres kivétel-specifi- 
kációval rendelkező memóriafoglalók által visszaadott értéket mindig ellenőrzi, és ha 0 ér- 
téket kap, nem hívja meg a konstruktort, hanem azonnal szintén 0 értéket ad vissza. 
A nothrow memóriafoglalók például 0 értéket adnak vissza a sikertelen helyfoglalás jelzé- 
sére, és nem egy bad alloc kivételt váltanak ki: 


void JO 


( 
int" p - new int(100000/; // bad alloc-ot válthat ki 


if (int g - neu(nothrow) int([100000)) f // nem vált ki kivételt 
// lefoglalás sikeres 
) 
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else ( 
// lefoglalás sikertelen 
j 


j 


Ez a módszer lehetővé teszi, hogy kivétel előtti hibakezelést használjunk a helyfoglalás során. 


19.4.6. C stílusú helyfoglalás 


A C44 a C-től örökölt egy dinamikusmemória-kezelő felületet, melyet a ccsidlib: fejállo- 
mányban találhatunk meg: 


void? malloccsize t 5); // s bájt lefoglalása 

void" calloc(size tn, size t 5); // n-szer s bájt feltöltése 0 kezdőértékkel 

void free(void? p); . / a mallocO vagy callocO által lefoglalt szabad terület felszabadítása 
void" realloc(void" p, size t 5); // a p által mutatott tömb méretének módosítása S-re; 


Ezen függvények helyett használjuk inkább a new vagy a delete operátort, vagy a szabvá- 
nyos tárolók még magasabb szintű szolgáltatásait. A fenti eljárások előkészítetlen memóri- 
ával foglalkoznak, így a free0 például nem hív meg semmilyen destruktort a memóriaterü- 
let felszabadítására. A new és a delete megvalósításai használhatják ezeket a függvényeket, 
de számukra sem kötelező. Ha egy objektumot például a new operátorral hozunk létre, 
majd a freeO függvénnyel próbálunk meg megsemmisíteni, súlyos problémákba ütközhe- 
tünk. Ha a reallocO függvény szolgáltatásaira lenne szükségünk, használjunk inkább szab- 
ványos tárolókat, melyek az ilyen jellegű feladatokat általában sokkal egyszerűbben és leg- 
alább olyan hatékonyan hajtják végre (§16.3.5). 


A könyvtár tartalmaz néhány olyan függvényt is, melyekkel hatékonyan végezhetünk bájt- 
szintű műveleteket. Mivel a C a típus nélküli bájtokat eredetileg char" mutatókon keresztül 
érte el, ezek a függvények a ccstring: fejállományban találhatók. Ezekben a függvények- 
ben a void" mutatókat char" mutatókként kezeljük: 


void? memcpy(void" p, const void" g, size tn); // nem átfedő területek másolása 
void? memmove(void" p, const void" g, size tn); // esetleg átfedő területek másolása 


A strcpyO (§20.4.1) függvényhez hasonlóan ezek a műveletek is n darab bájtot másolnak 
a g címről a p címre, majd a p mutatót adják vissza. A memoveg által kezelt memóriaterü- 
letek átfedhetik egymást, de a memcpyő feltételezi, hogy a két terület teljesen különálló, és 
általában ki is használja ezt a feltételezést. 
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Hasonlóan működnek az alábbi függvények is: 


void? memchrcconst void?" p, int b, size tn); // mint a strchrO (§20.4. 1: 
// b keresése pf0J. pln-1/-ben 

int memcmp(const void? p, const void" g, size tn); // mint a strcmpO: bájtsorozatok 
// összehasonlítása 

void? memset(void" p, int b, size t n); // n bájt b-re állítása, p 
// visszaadása 


Számos Ct-4-változatban ezeknek az eljárásoknak erősen optimalizált változatai is 
megtalálhatók. 


19.5. Tanácsok 


[1] 


[2] 


[3] 


[4] 


[5] 


[6] 


[7] 
[8] 


[91 
[10] 


[11] 
[12] 


Amikor egy algoritmust megírunk, döntsük el, milyen bejáróra van szükségünk 
az eljárás kellően hatékony megvalósításához, majd folyamatosan figyeljünk, 
hogy csak olyan műveleteket használjunk, melyek az adott bejáró-kategória 
esetében rendelkezésünkre állnak. §19.2.1 

Az algoritmusok hatékonyabb megvalósítására használjunk túlterhelést, ha a pa- 
raméterként megadott bejáró a minimális követelménynél több szolgáltatást 
nyújt. 519.2.3. 

A különböző bejáró-kategóriákra használható algoritmusok megírásához hasz- 
náljuk az iterator. traits osztályokat. §19.2.2. 

Ne felejtsük el használni a 4- operátort az istream, iterator és az 

ostream, iterator objektumok esetében sem. §19.2.6. 

A tárolók túlcsordulásának elkerülése érdekében használjunk beszúró Cinserter) 
bejárókat. §19.2.4. 

Tesztelés alatt végezzünk minél több ellenőrzést, és a végleges változatból is 
csak azokat távolítsuk el, melyeket feltétlenül szükséges. §19.3.1. 

Ha tehetjük, használjuk a 4-pb formát a p-t- helyett. §19.3. 

Az adatszerkezeteket bővítő algoritmusok hatékonyságát növelhetjük, ha előké- 
szítetlen memóriaterületeket használunk. §19.4.4. 

Ha egy algoritmus ideiglenes adatszerkezeteket használ, a hatékonyságot ideig- 
lenes tár (puffer) használatával növelhetjük. §19.4.4. 

Kétszer is gondoljuk meg, mielőtt saját memóriafoglaló írásába kezdünk. §419.4. 
Kerüljük a mallocO), a freeO, a reallocO stb. függvények használatát. §19.4.6. 

A sablonok typedef-jeinek használatát a rebind függvénynél bemutatott módszer 
segítségével utánozhatjuk. §19.4.1. 
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19.6. Gyakorlatok 


HA 0 [443 


asd Gx 


. G1.5) Készítsük el a §18.6.7. reverseO függvényét. Segítség: §19.2.3. 
. (1.5) Készítsünk egy kimeneti bejárót, amely valójában sehova sem ír. Mikor 


lehet értelme egy ilyen bejárónak? 


. (2) Írjuk meg a reverse iterator osztályt (419.2.5). 

. G1.5) Készítsük el az ostream, iterator osztályt (§19.2.0). 

. G2) Készítsük el az istream. iterator osztályt (§19.2.06). 

. (2.5) Fejezzük be a Checked iter osztályt (419.3). 

. 2.5) Alakítsuk át a Checked iter osztályt úgy, hogy ellenőrizze az érvénytelen- 


né vált bejárókat is. 


. (2) Tervezzünk meg és készítsünk el egy olyan kezelőosztályt, amely egy táro- 


lót képes helyettesíteni úgy, hogy annak teljes felületét biztosítja. Az ábrázolás- 
ban tárolnunk kell egy mutatót egy tárolóra, valamint meg kell írnunk a tároló 
műveleteit tartományellenőrzéssel. 


. (C2.5) Fejezzük be vagy írjuk újra a Pool alloc (419.4.2) osztályt úgy, hogy az 


a standard könyvtár allocator (§19.4.1) osztályának minden lehetőségét támo- 
gassa. Hasonlítsuk össze az allocator és a Pool alloc hatékonyságát, és állapít- 
suk meg, hogy saját rendszerünkben szükség van-e a Pool alloc használatára. 


10.(C2.5) Készítsünk el egy vector osztályt úgy, hogy memóriafoglalókat haszná- 


lunk a new és a delete operátor helyett. 
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Karakterláncok 


,Járt utat a járatlanért el ne hagyj" 


Karakterláncok s Karakterek e char. traits s basic string s Bejárók s Elemek elérése e 
Konstruktorok e Hibakezelés e Értékadás s Koverzió e Összehasonlítás s Beszúrás 
e Összefűzés e Keresés és csere s Méret és kapacitás s Karakterláncok ki- és bevitele 
e C stílusú karakterláncok e Karakterek osztályozása s A C könyvtár függvényei s Taná- 
csok s Gyakorlatok 


20.1. Bevezetés 


A karakterlánc (string) karakterek sorozata. A standard könyvtár string osztálya mindazokat 
az eljárásokat elérhetővé teszi, amelyekre a karakterláncokkal kapcsolatban szükségünk le- 
het: indexelés (420.3.3), értékadás (420.3.69, összehasonlítás (420.3.8), hozzáfűzés (420.3.9), 
összefűzés (420.3.10), részláncok keresése (420.3.11). Nincs viszont általános részlánc-keze- 
lő, ezért — a szabványos string használatát is bemutatandó — készítünk majd egyet 
(420.3.119. Egy szabványos karakterlánc szinte bármilyen karakterek sorozata lehet (420.2). 
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A tapasztalatok azt mutatják, hogy nem lehet tökéletes szring típust megvalósítani. Ehhez az 
emberek ízlése, elvárásaik, igényeik túl nagy mértékben különböznek. Így a standard 
könyvtár string osztálya sem tökéletes. Bizonyos tervezési kérdésekben máshogy is dönt- 
hettem volna az osztály létrehozásakor. Ennek ellenére azt hiszem, sok elvárást kielégít és 
könnyen elkészíthetők azok a kiegészítő függvények, melyekkel a további feladatok meg- 
oldhatók. Nagy előnyt jelent az is, hogy az std::string osztály általánosan ismert és minden- 
hol elérhető. Ezek a jellemzők a legtöbb esetben fontosabbak, mint azok tulajdonságok, 
amelyekkel az osztályt esetleg még kiegészíthetnénk. A különböző karakterlánc-osztályok 
elkészítése gyakorlásnak nagyszerű (411.12, §13.29, de ha széles körben használható válto- 
zatot akarunk, akkor a standard könyvtár string osztályára lesz szükségünk. 


A C44 a C-től örökölt, nullával lezárt karaktertömbként értelmezett karakterláncok (vagyis 
a C stílusú karakterláncok) kezelésére a standard könyvtárban számos külön függvényt biz- 
tosít (420.4.1). 


20.2. Karakterek 


A , karakter" (character) már önmagában is érdekes fogalom. Figyeljük meg például a Cka- 
raktert. Ezt a Cbetűt, amely valójában egy egyszerű félkörív a papíron (vagy a képernyőn), 
hónapokkal ezelőtt gépeltem be a számítógépembe. Ott egy 8 bites bájtban a 67 számér- 
tékként tárolódott. Elmondhatjuk róla, hogy a latin ábécé harmadik betűje, a hatodik atom 
(a szén, carbon) szokásos rövidítése és mellesleg egy programozási nyelv neve is (41.09. 
A karakterláncok programokban való felhasználásakor csak az számít, hogy e kacskaringós 
alakzathoz kapcsolódik egy hagyományos jelentés, amit karakternek nevezünk, és egy 
számérték, amit a számítógép használ. Hogy bonyolítsuk a dolgokat, ugyanahhoz a karak- 
terhez a különböző karakterkészletekben más-más számérték tartozhat, sőt, nem is minden 
karakterkészletben találunk számértéket minden karakterhez, ráadásul sok különböző ka- 
rakterkészletet használunk rendszeresen. A karakterkészlet nem más, mint a karakterek 
(a hagyományos szimbólumok) egy leképezése egész értékekre. 


A C34 programozók általában feltételezik, hogy a szabványos amerikai karakterkészlet 
(ASCID rendelkezésünkre áll, de a C-t felkészült arra az esetre is, ha bizonyos karakterek 
hiányoznának a programozási környezetből. Például ha olyan karakterek hiányoznak, mint 
a / vagy a íf, használhatunk helyettük kulcsszavakat vagy digráf — két tagból álló — jeleket 
(4C.3.1. 
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Nagy kihívást jelentenek azok a karakterkészletek is, melyekben olyan karakterek szerepel- 
nek, amelyek az ASCII-ban nem fordulnak elő. Az olyan nyelvek karakterei, mint a kínai, 
a dán, a francia, az izlandi vagy a japán, nem írhatók le hibátlanul az ASCII karakterkészlet 
segítségével. Még nagyobb probléma, hogy az e nyelvekhez használt karakterkészletek is 
különböznek. A latin ábécét használó európai nyelvek karakterei például majdnem elfér- 
nek egy 256 karakteres karakterkészletben, de sajnos a különböző nyelvekhez különböző 
készleteket használunk és ezekben néha különböző karaktereknek ugyanaz az egész érték 
jutott. A francia karakterkészlet (amely Latin1-et haszná) például nem teljesen egyeztethe- 
tő össze az izlandi karakterekkel (így azok használatához a Latin2 készletre van szüksé- 
günk). Azok a nagyratörő kísérletek, melyek során megpróbáltak minden, emberek által 
ismert karaktert egyetlen karakterkészletben felsorolni, sok problémát megoldottak, de 
még a 16 bites készletek (például a Unicode) sem elégítettek ki minden igényt. A 32 bites 
karakterkészletek, melyek — ismereteim szerint — az összes karakter megjelölésére alkalma- 
sak lennének, még nem terjedtek el széles körben. 


A Cs- alapvetően azt a megközelítést követi, hogy a programozónak megengedjük bárme- 
lyik karakterkészlet használatát a karakterláncok karaktertípusának megadásához. Használ- 


hatunk bővített karakterkészleteket és más rendszerre átültethető számkódolást is (§C.3.3) 


20.2.1. Karakterjellemzők 


A §13.2 pontban már bemutattuk, hogy egy karakterlánc elméletileg tetszőleges típust ké- 
pes , karakterként" használni, ha az megfelelő másolási műveleteket biztosít. Csak azokat 
a típusokat tudjuk azonban igazán hatékonyan és egyszerűen kiaknázni, melyeknek nincs 
felhasználói másoló művelete. Ezért a szabványos string osztály megköveteli, hogy a ben- 
ne karakterként használt típusnak ne legyen felhasználói másoló művelete. Ez azt is lehe- 
tővé teszi, hogy a karakterláncok ki- és bevitele egyszerű és hatékony legyen. 


Egy karaktertípus jellemzőit (traits) a hozzá tartozó char. traits osztály írja le, amely az 
alábbi sablon specializációja: 


templatexclass Ch: struct char. traits ( ); 


Minden char. traits az std névtérben szerepel és a szabványos változatok a cstring: fejál- 
lományból érhetők el. Az általános char. traits osztály egyetlen jellemzőt sem tartalmaz, 
azokkal csak az egyes karaktertípusokhoz készített változatok rendelkeznek. 
A char. traitséchar: definíciója például a következő: 
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templateS2 struct char. traitséchar: f // a char. traits műveleteknek nem szabad 
// kivételt kiváltaniuk 
typedef char char. type; // a karakter típusa 
static void assign(char. tybek, const char. typed ); // az - meghatározása a 


// char. type számára 


// a karakterek egész értékű ábrázolása 


typedef int int type; // a karakter-értékek egész típusa 
static char. type to char. type(const int typec ); // átalakítás int-ről char-ra 
static int type to int type(const char. typek ); // átalakítás char-ról int-re 
static bool eg int type(const int typek, const int type ); [—-—- 


// char. type összehasonlítások 


static bool eg(const char. typekg, const char. type ); [—-- 
static bool lt(const char. typek, const char. type ); a 


// műveletek sín] tömbön 

static char. type? move(char. type" s, const char. type" s2, size tn); 
static char. type? copy(char. type? s, const char. type" s2, size tn); 
static char. type? assign(char. type" s, size t n, char. type a); 

static int compare(const char. type" s, const char. type" s2, size tn); 
static size t length(const char. type"); 


static const char. type" find(const char. type" s, int n, const char. typek ); 


// bemeneti/kimeneti műveletek 


typedef streamoff off type; // eltolás az adatfolyamban 

typedef streampos pos type; // pozíció az adatfolyamban 

typedef mbstate t state type; // több bájtos adatfolyam állapota 
static int type eofO; // fájl vége 

static int type not eof(const int typeg i); // i, hacsak i értéke nem eofO; 
static state type get state(pos type p9; // b bozíción levő karakter 





// állapota a több bájtos átalakítás során 
2. 
43 
A szabványos karakterlánc-sablon, a basic string (420.3) megvalósítása e típusokon és 
függvényeken alapul. A basic string-hez használt karaktertípusnak rendelkeznie kell egy 


olyan char. traits specializációval, amely mindezeket támogatja. 
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Ahhoz, hogy egy típus cAar. type lehessen, képes kell legyen arra, hogy minden karakter- 
hez hozzárendeljen egy egész értéket, melynek típusa int type. Az int type és a char. tybe 
típus közötti átalakítást a to char. typeO és a to int typeO függvény hajtja végre. A char tí- 
pus esetében ez a átalakítás igen egyszerű. 


A move(s,s2,n) és a copy(s,s52,n) függvények egyaránt az s2 címről másolnak át n karaktert 
az s címre, és mindketten az assign(s[ij, s2li/) utasítást használják. A különbség az, hogy 
a movel akkor is helyesen működik, ha s2 az /s,5--n/ tartományba esik, a copyO viszont ki- 
csit gyorsabb. Ez a működési elv pontosan megegyezik a C standard könyvtár memcpyO, 
illetve memmoveO (§19.4.6) függvényeinek működésével. Az assign(5,n,x) függvényhívás 
az x karakter n darab másolatát írja az s címre az assign(s[i/,x) utasítás segítségével. 


A compareO függvény a HO) illetve az egŐ eljárásokat használja a karakterek összehason- 
lításához. Visszatérési értéke egy int, amely O, ha a két karakterlánc pontosan megegyezik; 
negatív szám, ha az első paraméter ábécésorrendben előbb következik, mint a második; 
fordított esetben pozitív szám. A visszatérési érték ilyen használata a C standard könyvtár 
strcempO függvényének működését követi (420.4.1). 


A ki- és bemenethez kapcsolódó függvényeket az alacsonyszintű [/D műveletek használják 


(421.6.49. 


A széles karakterek (amelyek a wcAhar. t osztály példányai, §4.3) nagyon hasonlítanak az 
egyszerű char típushoz, de kettő vagy még több bájtot használnak. A wchar. t típus tulaj- 
donságait a char. traitsZwchar. t- osztály írja le: 


templates2 struct char. traitsZwchar. t2 ( 
typedef wchar. t char. type; 
typedef wint t int type; 


typedef wstreamojf off type; 
typedef wstreampos pos type; 


// mint a char. traitskchar: 


); 


A wchar. ttípust elsősorban a 16 bites karakterkészletek (például a Unicode) karaktereinek 
tárolásához használjuk. 
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20.3. A basic string osztály 


A standard könyvtár karakterláncokhoz kapcsolódó szolgáltatásai a basic string sablonon 
(template) alapulnak, amely hasonló típusokat és műveleteket biztosít, mint a szabványos 


tárolók (§16.39: 


templatexclass Ch, class Tr - char. traitsZCh:, class A - allocatorzCh: 5 
class std::basic string ( 
bublic: 
VET 
37 
A sablon és a hozzá kapcsolódó szolgáltatások az szd névtérhez tartoznak és a cstring? fej- 
állományon keresztül érhetők el. 


A leggyakoribb karakterlánc-típusok használatát két typedef könnyíti meg: 


typedef basic stringcchar? string; 
typedef basic stringCwchar. t2 wstring; 


A basic string sok mindenben hasonlít a vector (416.3) osztályra. A legfontosabb eltérés, 
hogy a basic string nem tartalmazza az összes eljárást, amely a vector osztályban megtalál- 
ható, helyettük néhány, jellegzetesen karakterláncokra vonatkozó műveletet (például rész- 
lánc-keresést) biztosít. A string osztályt nem érdemes egy egyszerű tömbbel vagy a vector 
típussal megvalósítani; a karakterláncok nagyon sok felhasználási módja jobban biztosítha- 
tó úgy, ha a másolások mennyiségét a lehető legkevesebbre csökkentjük, nem használunk 
dinamikus adatterületet a rövid karakterláncokhoz, a hosszabbaknál egyszerű módosítha- 
tóságot biztosítunk és így tovább (420.6[12D. A string osztály függvényeinek száma jelzi 
a karakterláncok kezelésének fontosságát, és azt is, hogy bizonyos számítógépek különle- 
ges hardverutasításokkal segítik ezeket a műveleteket. A könyvtárak készítői akkor használ- 
hatják ki legjobban az ilyen függvények előnyeit, ha a standard könyvtárban találnak 
hasonlókat. 


A standard könyvtár más típusaihoz hasonlóan a basic stringZT: is egy konkrét típus 
(42.5.3, §10.3), virtuális függvények nélkül. Bátran felhasználhatjuk tagként egy magasabb 
szintű szövegfeldolgozó osztályban, de arra nem való, hogy más osztályok bázisosztálya le- 
gyen (425.2.1, lásd még §20.6[10). 
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20.3.1. Típusok 


A vector osztályhoz hasonlóan a basic string is típusneveken keresztül teszi elérhetővé 
a vele kapcsolatban álló típusokat: 


templatexclass Ch, class Tr - char. traiszCh:, class A - allocatorzCh: 5 
class basic string ( 
public: 

// típusok (mint a vector-nál, a list-nél stb., §16.3.1) 


typedef Tr traits type; // a basic string-re jellemző 


typedef typename Tr::char. type value type; 

typedef A allocator. type; 

typedef typename A::size type size type; 

typedef typename A::difference type difference type; 


typedef typename A::reference reference; 

typedef typename A::const reference const reference; 
typedef typename A::pointer pointer; 

typedef typename A::const pointer const pointer; 


typedefmegvalósítás függő iterator; 
typedefmegvalósítás függő const iterator; 


typedef std::reverse iteratorZiterator: reverse iterator; 
typedef std::reverse iteratorcconst iterator: const reverse iterator; 


VAN 
); 


A basic string az egyszerű basic string£char? típus mellett (melyet string néven ismerünk) 
számos karaktertípusból tud karakterláncot képezni: 


typedef basic stringZunsigned char? UString; 


struct Jchar £/5 ... "79; // japán karaktertípus 
typedef basic string2Jchar? Jstring; 


Az ilyen karakterekből képzett karakterláncok ugyanúgy használhatók, mint a chartípuson 
alapulók, csak a karakterek szerepe szabhat határt: 


Ustring first word(const Ustringft us) 


( 
Ustring::size type pos — us findC ",; // §20.3.11 
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return Ustring(us, O,pos); // 5620.3.4 


j 


Jstring first word(const Jstringé js) 

( 
Jstring::size type pos — js findC "; // §20.3.11 
return Jstring(js, O,pos9; // 5620.3.4 


j 


Természetesen használhatunk olyan sablonokat is, melyek karakterlánc-paramétereket 
használnak: 


templatecciass S2 S first word(const S£ 5) 

( 
typename S::size type pos — s findC ",; // §20.3.11 
return S(s,O,Do5s); // 520.3.4 


J 


A basic stringZCh: bármilyen karaktert tartalmazhat, amely szerepel a C7 típusban, tehát 
például a 0 (nulla) karakter is előfordulhat a karakterlánc belsejében. A CZ , karaktertípus- 


nak" úgy kell viselkednie, mint egy karakternek, tehát nem lehet felhasználói másoló 
konstruktora, destruktora, vagy másoló értékadása. 


20.3.2. Bejárók 


A többi tárolóhoz hasonlóan a szring osztály is biztosít néhány bejárót (iterátor)), melyek- 
kel végighaladhatunk az elemeken, akár a szokásos, akár fordított sorrendben: 


templatexcilass Ch, class Tr - char. traitsZCh:, class A - allocatorZCh: 5 
class basic string ( 
bublic: 

VÁROS 

// bejárók (mint a vector-nál, a list-nél stb., §16.3.2) 


iterator beginO; 

const iterator beginŐ const; 
iterator endő; 

const iterator endŐ const; 


reverse iterator rbeginO; 

const reverse iterator rbeginŐ const; 
reverse iterator rendO; 

const reverse iterator rendŐ const; 


Ms 


20. Karakterláncok 783 


Mivel a string osztályban megtalálhatók a bejárók kezeléséhez szükséges tagtípusok és 
-függvények, a szabványos algoritmusok (18. fejezet) string objektumokra is használhatók: 


void f(stringéz 5) 

f 
string::iterator p - find(s.beginO,s.endO, a"; 
1 sz 

J 


A karakterláncokra leggyakrabban alkalmazott műveleteket közvetlenül a szring osztályban 
találhatjuk meg. Remélhetőleg ezeket a műveleteket kifejezetten a karakterláncokhoz iga- 
Zították, így jobbak, mint az általános algoritmusok. 


A szabványos algoritmusok (18. fejezet) a karakterláncok esetében nem annyira hasznosak, 
mint első ránézésre gondolnánk. Az általános műveletek azt feltételezik, hogy a tárolók ele- 
mei önmagukban is értelmes egységet alkotnak, de a karakterláncok esetében a teljes ka- 
raktersorozat hordozza a lényeges információt. Egy karakterlánc rendezése (pontosabban 
a karakterlánc karaktereinek rendezése) szinte teljesen megsemmisíti a benne tárolt infor- 
mációkat, annak ellenére, hogy az általános tárolókban a rendezés inkább még használha- 
tóbbá szokta tenni az adatokat. 


A string osztály bejárói sem ellenőrzik, hogy érvényes tartományban állnak-e. 


20.3.3. Az elemek elérése 


A string-ek karaktereit egyesével is elérhetjük, indexelés segítségével: 


templatexclass Ch, class Tr - char. traiszCh:, class A - allocatorzCh: 5 
class basic string ( 
bublic: 

sss 


// elemek elérése (mint a vector-nál, §16.3.39: 


const reference operatorf (size type n) const; // nem ellenőrzött hozzáférés 
reference operatori I(size type n); 


const reference at(size type n) const; // ellenőrzött hozzáférés 
reference at(size type n); 


VAA 
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Ha az atO függvény használatakor a megengedett tartományon kívüli indexértéket (sorszá- 
mot) adunk meg, out of range kivétel váltódik ki. 


A vector osztálytól eltérően a sztring nem tartalmazza a frontO és a backO függvényt. Ha 
a karakterlánc első vagy utolsó elemére akarunk hivatkozni, az s/0/ vagy az s/s.lengthO-1/ 
kifejezést kell használnunk. A mutató-tömb egyenértékűség (45.3) a karakterláncok eseté- 
ben nem teljesül: ha s egy sztring, akkor a £s/0/ nem egyezik meg s értékével. 


20.3.4. Konstruktorok 


A kezdeti értékadáshoz, illetve a másolási műveletek elvégzéséhez a sztring más függvénye- 
ket kínál, mint az egyéb tárolók (416.3.49: 


templatexcilass Ch, class Tr - char. traitsZCh:, class A - allocatorzCh: 5 
class basic string ( 
bublic: 
Moses 
// konstruktorok stb. (csak nagyjából úgy, mint a vector-nál és a list-nél, §16.3.4) 


explicit basic string(const A£ a - 409; 
basic string(const basic stringdt s, 
size type pos — O, size type n - npos, const A£ a - AO9; 
basic string(const Ch" p, size type n, const A£ a - 409; 
basic string(const Ch" p, const A£ a - A09; 
basic string(size type n, Ch c, const A£ a - A09; 
templatexclass In: basic string(In first, In last, const A£ a - 409; 


-basic stringO; 
static const size type npos; // "minden karakter" 


Masa 


J; 


Egy string objektumnak C stílusú karakterlánccal, másik string objektummal, annak egy 


részével, vagy karakterek egy sorozatával adhatunk kezdőértéket, karakterrel vagy egész 
értékkel nem: 


void (char? p,vectorcchar:£v) 

( 
string SO; // üres karakterlánc 
string 500 — "; // ez is üres karakterlánc 
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string 51 — ta; // hiba: nincs konverzió char-ról string-re 

string 52 — 7; // hiba: nincs konverzió int-ről string-re 

string 3079; // hiba: a konstruktornak nem lehet egy int paramétere 
string s4(7, a); // 7 darab ta, vagyis "aaaaaaa" 

string s5 — "Frodo"; // "Frodo" másolata 

string 56 — 55; // 55 másolata 

string s7(55,3,29; 17 5503] és s5[4l, vagyis "do" 

string s8(pt7,39; // pl7I, pls], és pl9/ 

string s9(p, 7.39; // string(string(p), 7,3), valószínűleg "költséges" 


string s10(v.beginO, v.endO); // v minden karakterének másolása 


A karakterek helyét nullától kezdve indexeljük, tehát egy karakterlánc nem más, mint 0-tól 
lengthO-1-ig számozott karakterek sorozata. 


A lengthO függvény a string esetében a size0 megfelelője: mindkettő a karakterláncban 
szereplő karakterek számát adja meg. Figyeljünk rá, hogy ezek nem egy C stílusú karakter- 
lánc hosszát állapítják meg, tehát nem számolják a lezáró nullkaraktert (420.4.1). 
A basic string osztályt a lezáró karakter alkalmazása helyett a karakterlánc hosszának táro- 
lásával illik megvalósítani. 


A részláncokat a kezdőpozíció és a karakterszám megadásával azonosíthatjuk. Az alapértel- 
mezett npos értéke a lehető legnagyobb szám, jelentése ,az összes elem". 


Nincs olyan konstruktor, amely n darab meghatározatlan karakterből hoz létre karakterlán- 
cot. Ehhez legközelebb talán az a konstruktor áll, amely egy adott karakter n példányából 
épít fel egy karakterláncot. Az olyan konstruktorok hiánya, melyeknek egyetlen karaktert 
vagy csak a karakterláncban lévő karakterek számát adnánk meg, lehetővé teszi, hogy a for- 
dító észrevegyen olyan hibalehetőségeket, amilyeneket az 52 és az s3 fenti meghatározása 


rejt magában. 


A másoló konstruktor egy négyparaméterű konstruktor. E paraméterek közül háromnak 
alapértelmezett értéke van. A hatékonyság érdekében két különálló konstruktorként is el- 
készíthetjük; a felhasználó nem lesz képes különbséget tenni a két megoldás között, ha a le- 
fordított kódot meg nem nézi. 
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A legáltalánosabb konstruktor egy sablon tagfüggvénye. Ez lehetővé teszi, hogy a karakter- 
lánc kezdőértékét tetszőleges sorozatból állítsuk elő, például egy más karaktertípust hasz- 
náló karakterlánc segítségével, amennyiben a karaktertípusok közötti konverzió rendelke- 


zésünkre áll: 


void f(string 5) 
( 


wstring ws(s.beginO,s.endO); // s minden karakterének másolása 


VESE 


J 


A ws karakterlánc minden wchar. tkarakterének az s megfelelő char eleme ad kezdőértéket. 


20.3.5. Hibák 


A karakterláncokat igen egyszerűen olvashatjuk, írhatjuk, megjeleníthetjük, tárolhatjuk, 
összehasonlíthatjuk, lemásolhatjuk stb. Ez általában nem okoz problémákat, legfeljebb 
a hatékonysággal támadhatnak gondjaink. Ha azonban elkezdünk karakterláncok egyes 
részláncaival, karaktereivel foglalkozni és így létező karakterláncokból akarunk újakat 
összeállítani, előbb-utóbb hibákat fogunk elkövetni, melynek következtében a karakterlánc 
határain kívülre próbálunk meg írni. 


Az egyes karakterek közvetlen elérésére szolgáló az0 függvény ellenőrzi az ilyen hibákat 
és out-of range kivételt vált ki, ha érvénytelen hivatkozást adunk meg. A / / operátor ilyen 
vizsgálatot nem végez. 


A legtöbb karakterlánc-műveletnek egy karakterpozíciót és egy karakterszámot kell meg- 
adnunk. Ha a megadott pozícióérték nagyobb, mint a karakterlánc mérete, azonnal 
out of range kivételt kapunk; ha a karakterszám , túl nagy", értelmezése általában az lesz, 
hogy az összes hátralévő karaktert használni akarjuk: 


void JO 
( 
string s - "Snobold"; 
string s2(s, 100, 29; // a megadott karakterpozíció a lánc végén tűl van: 
// out of rangeO váltódik ki 
string s3(5, 2, 1009; // a karakterszám túl nagy: egyenértékű a s3(5,2,s5.size0-2) 
// kifejezéssel 


string s4(s,2,string::npos);  // az s[2]-től kezdődő összes karakter 
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A túl nagy" karakterpozíciókat ki kell szűrnünk, de a ,túl nagy" karakterszám hasznos le- 
het a programokban. Valójában az npos a lehető legnagyobb size type típusú érték. 


Érdemes kipróbálnunk, mi történik akkor, ha negatív karakterpozíciót vagy karakterszámot 
adunk meg: 


void g(stringf 5) 

f 
string s5(s,-2,3); / nagy pozícióérték!: out of rangeO 
string S56(s,3,-2; // nagy karakterszám!: rendben 


J 


Mivel a size type típust arra használjuk, hogy pozíciókat vagy darabszámokat adjunk meg, 
unsignedtípusként definiált, így a negatív számok használata csak félrevezető módja a nagy 
pozitív számok megadásának (§16.3.4). 


Azok a függvények, amelyek egy sziring részláncát keresik meg (§20.3.11), az npos értéket 
adják vissza, ha nem találják meg a megfelelő részt. Tehát maguk nem váltanak ki kivételt, 
de ha ezt az npos értéket karakterpozícióként akarjuk felhasználni a következő műveletben, 
akkor már kivételt kapunk. 


Egy részlánc kijelölésének másik módja, hogy két bejárót (iterator) adunk meg. Az első ha- 
tározza meg a pozíciót, míg a két bejáró különbsége a karakterszámot. Szokás szerint 
a bejárók nem ellenőrzöttek. 


Ha C stílusú karakterláncokat használunk, a tartományellenőrzés nehezebb feladat. Ha pa- 
raméterként adunk meg ilyen karakterláncot (tehát egy cAar-ra hivatkozó mutatót), 
a basic string függvényei feltételezik, hogy a mutató nem O. Ha egy C stílusú karakterlánc- 
ban pozíciót adunk meg, a függvények elvárják, hogy a karakterlánc elég hosszú legyen 
a pozíció értelmezéséhez. Mindig legyünk nagyon óvatosak, sőt kifejezetten gyanakvóak. 
Az egyetlen kivétel, amikor karakterliterálokat használunk. 


Minden karakterlánc esetében igaz, hogy lengthOOznpos. Néhány nagyon egyedi helyzetben 
Cigen ritkán) előfordulhat, hogy egy olyan jellegű művelet, mint egy karakterlánc beszúrá- 
sa egy másikba, túl hosszú karakterláncot eredményez, amelyet a rendszer már nem képes 
ábrázolni. Ebben az esetben length error kivétel keletkezik: 


string s(string::npos, a); // length errorOÓ váltódik ki 
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20.3.6. Értékadás 


Természetesen a karakterláncok esetében is rendelkezésünkre áll az (egyszerű) értékadás 
művelete: 


templatexcilass Ch, class Tr - char. traitsZCh:, class A - allocatorZCh: 5 
class basic string ( 
bublic: 

Ve 

// értékadás (kicsit hasonlít a vector-ra és a list-re, §16.3.4: 


basic stringkt oberator—(const basic stringét 5); 
basic stringkt oberator—(const Ch" p); 
basic stringkt oberator—(Ch c); 


basic stringít assign(const basic stringf ); 

basic stringk assign(const basic stringét s, size type pos, size type n); 
basic stringkt assign(const Ch? p, size tybe n); 

basic stringkz assign(const Ch? p); 

basic stringk assign(size type n, Ch c); 

templatexclass In: basic stringk assign(In first, In last); 


Jé sai 


J; 
A többi tárolóhoz hasonlóan a sztring osztályban is érték szerinti értelmezés működik, ami 
azt jelenti, hogy amikor egy karakterláncot értékül adunk egy másiknak, akkor az eredeti 
karakterláncról másolat készül, és az értékadás után két, ugyanolyan tartalmú, de önálló 
(értékű) karakterlánc áll majd rendelkezésünkre: 


void g0 
( 
string s1 - "Knold"; 
string s2 — "Tot"; 
s1 — s2; // "Tot"-ból két példány lesz 
S21] - u; // 52 "Tut", 51 marad "Tot" 


j 


Annak ellenére, hogy egyetlen karakterrel nem adhatunk kezdőértéket egy karakterlánc- 
nak, az ilyen módon történő egyszerű értékadás megengedett: 


void JO 

( 
string s — la; // hiba: kezdeti értékadás char-ral 
s- a; // rendben: egyszerű értékadás 
s - ga h. 


$-S; 


20. Karakterláncok 789 


Az a lehetőség, hogy karakterláncnak értékül adhatunk egy karaktert, nem túlságosan hasz- 
nos, és sok hibalehetőséget rejt magában. Gyakran azonban nélkülözhetetlen, hogy egy ka- 
raktert a 4- művelettel hozzáfűzhessünk egy karakterlánchoz (420.3.9), és igen furcsán néz- 
ne ki, ha az s4-(c" utasítás végrehajtható lenne, míg az s- c" nem. 


Az értékadáshoz az assignO nevet használjuk, amely a többparaméterű konstruktorok meg- 
felelőjének tekinthető (4176.3.4, §20.3.4). 


A §11.12 pontban már említettük, hogy a string osztály optimalizálható úgy, hogy amíg 
nincs szükség egy karakterlánc két példányára, addig nem hajtjuk végre a tényleges máso- 
lást. A szabványos sztring felépítése támogatja az ilyen takarékosan másoló megvalósítások 
létrehozását, mert így hatékonyan írhatunk le csak olvasható karakterláncokat, és a karak- 
terláncok átadása függvények paramétereként sokkal egyszerűbben megvalósítható, mint 
azt első ránézésre gondolnánk. Az azonban meggondolatlanság lenne, ha egy programozó 
saját fejlesztőkörnyezetének ellenőrzése nélkül olyan programokat írna, amelyek a szring- 
ek optimalizált másolására támaszkodnak (420.6[13). 


20.3.7. Átalakítás C stílusú karakterláncra 


A §20.3.4 pontban bemutattuk, hogy a string objektumoknak való kezdeti és egyszerű 
értékadásra egyaránt használhatunk C stílusú karakterláncokat. Fordított irányú műveletek 
elvégzésére is van lehetőség, tehát egy szring karaktereit is elhelyezhetjük egy tömbben: 


templatexclass Ch, class Tr - char. traiszCh:, class A - allocatorzCh: 5 
class basic string f( 
bublic: 

Ms 


// átalakítás C stílusú karakterlánccá 


const Ch" c strÓ const; 
const Ch?" dataO const; 
size type copy(Ch" p, size type n, size type pos - 0) const; 


14 st 
Va 


A data0 függvény a string karaktereit egy tömbbe másolja, majd visszaad egy erre a tömb- 
re hivatkozó mutatót. A tömb a string objektumhoz tartozik, tehát a felhasználónak nem 
szabad törölnie azt és a sztring egy nem const függvényének meghívása után már nem tud- 
hatja, milyen érték van benne. A c strO függvény szinte pontosan ugyanígy működik, csak 
a karakterlánc végén elhelyez egy 0 (nulD karaktert is, a C stílusú lezárásnak megfelelően: 
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void JO 
( 
string s - "eguinox"; /7 s. length0--7 
const char?" p1 - s.dataO; //p1 hét karakterre mutat 
bprintfCp1 - 95 pD; // hiba: hiányzó lezáró 
b1(2] - a; // hiba: p1 konstans tömbre mutat 
s/2] - a; 
char c - p1(1]; // hiba: s.dataO elérésének kísérlete s módosítása után 


const char? p2 - s.c strO; //p2 nyolc karakterre mutat 
brintfCp2 - 98 p2; // rendben: c strO hozzáadja a lezáró karaktert 


A különbséget úgy is megfogalmazhatjuk, hogy a data0 a karakterek egy tömbjét adja 
vissza, míg a c strO egy C stílusú karakterláncot állít elő. Ezen függvények elsődleges fel- 
adata, hogy könnyen használhatóvá tegyék az olyan függvényeket, melyek C stílusú karak- 
terláncot várnak paraméterként. Így tehát a c strO függvényt sokkal gyakrabban használ- 
juk, mint a dataÓ eljárást: 


void f(string 5) 

( 
int i — atoi(s.c StrO); // a karakterlánc int értékének lekérése (§20.4.1) 
ség 


j 
Általában érdemes a karaktereket mindaddig egy string objektumban tárolni, amíg nincs rá- 
juk szükségünk, de ha mégsem tudjuk azonnal feldolgozni, akkor is érdemes átmásolni 
azokat a c strO), illetve a dataO által lefoglalt területről egy külön tömbbe. A copyO függ- 
vény pontosan erre szolgál: 


char? c string(const string 5) 

( 
char?" p - new charis.lengthOt1]; . / megjegyzés: 31 
s.copy(p,string::npos); 
pls.lengthOJ - 0; // megjegyzés: lezáró hozzáadása 
return p; 


j 


Az s.copy(b,n,m) függvény legfeljebb n karaktert másol a bp címre az s/m/ pozíciótól kezd- 
ve. Ha az s karakterláncból n-nél kevesebb karaktert lehet csak átmásolni, a cobyO egysze- 
rűen az összes karaktert átmásolja. 
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Figyeljünk rá, hogy a string objektumokban szerepelhet a 0 karakter. A C stílusú karakter- 
láncokat kezelő függvények az első ilyen karaktert tekintik lezárónak. Tehát mindig figyel- 
jünk, hogy 0 karaktert csak akkor használjunk, ha C stílust használó függvényekre nem lesz 
szükségünk, vagy a 0-kat pontosan oda tegyük, ahol a karakterláncot le szeretnénk zárni. 


A C stílusú karakterláncra való átalakítást a c szrO helyett megoldhattuk volna egy operator 
const char" O művelettel is, az automatikus konverzió kényelmének azonban az lenne az 
ára, hogy meglepetésünkre időnként akkor is végbemenne, amikor nem is számítunk rá. 


Ha úgy érezzük, hogy programunkban sokszor lesz szükség a c strO függvényre, valószínű- 
leg túlságosan ragaszkodunk a C stílusú felülethez. Általában rendelkezésünkre állnak azok 
az eszközök, melyekkel a C stílusú karakterláncokra vonatkozó műveletek közvetlenül 
string objektumokon is elvégezhetők. Ezek használatával sok konverziót elkerülhetünk. Egy 
másik lehetséges megoldás az explicit konverziók elkerülésére az, hogy túlterheljük azokat 
a függvényeket, melyek a c sirO használatára kényszerítenek bennünket: 


extern "C" int atoi(const char? ); 


int atoi(const stringít s) 


( 


return atoi(s.c StrO); 


J 


20.3.8. Összehasonlítás 


Karakterláncokat azonos típusú karakterláncokkal vagy olyan karaktertömbökkel hasonlít- 
hatunk össze, melyek szintén ugyanolyan típusú karaktereket tartalmaznak: 


templatexclass Ch, class Tr - char. traiszCh:, class A - allocatorzCh: 5 
class basic string f( 
bublic: 

Méz 


int compare(const basic. string s) const; [/ 2 és -—— használata együtt 
int compare(const Ch? p) const; 


int comparecsize type pos, size type n, const basic stringdt s) const; 
int comparecsize type pos, size type n, 

const basic stringét s, size type pos2, size type n2) const; 
int compare(size type pos, size type n, const Ch"? p, size type n2 - npos) const; 


Zs 
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Ha a compareO meghívásakor a pozíció és méret paramétereket is megadjuk, csak a kijelölt 
részsorozat vesz részt az összehasonlításban. Például s.compare(pos,n,52) egyenértékű 
string(s,bos,n).compare(s29-vel. Az összehasonlító eljárást a char. traiszCh: osztály 
compare( függvénye adja (420.2.1). Így az s.compare(s2) függvény O értéket ad vissza, ha 
a karakterláncok egyenlő értékűek; negatív számot kapunk, ha s ábécésorrendben s2 előtt 
áll; fordított esetben pedig pozitív lesz az eredmény. 


A felhasználó itt nem adhat meg úgy összehasonlítási feltételt, mint a §13.4 pontban. Ha ilyen 
szintű rugalmasságra van szükségünk, a lexicographical compareO (§18.9) segítségével ké- 
szítsünk a fenti részben levőhöz hasonló összehasonlító függvényt. Egy másik lehetőség, 
hogy saját ciklust írunk a feladat megoldására. A toubberŐ függvény (420.4.2) például lehe- 
tővé teszi, hogy kis- és nagybetűkkel nem foglalkozó összehasonlítást valósítsunk meg: 


int cmp nocase(const string s, const stringd 52) 


( 
string::const iterator p -— s.beginO; 
string::const iterator p2 - s2.beginO); 


while (p/!-s.endŐ kk p2/-s2.endO) f 
if (toupperCp)!-touppberCp29) return (toupperCp)StoupperCp2)) ? -1 : 1; 


TED; 
14p2; 
j 
return (s52.size0--s.sizeO) ? 0 : (s.sizeOss2.sizeO) ? -1 : 1; // size! előjel nélküli 


j 


void Kconst stringét s, const stringdt 52) 


( 
if (s -—- 52) ( // kis- és nagybetűket figyelembe vevő összehasonlítás s és 52 között 
M/S 
j 
if (cmp nocase(s, 52) -——- 0) f /7 kis- és nagybetűket figyelmen kívül hagyó 
// összehasonlítás s és 52 között 
Mész 
j 
Mese 


A basic string osztályban rendelkezésünkre állnak a szokásos összehasonlító operátorok is 
(-- J-, 2, 5, cz 57): 
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templatexclass Ch, class Tr, class Az 
bool operator-—(const basic stringZCh, Tr,A2£, const basic stringZCh, Tr, A2£ ); 


templatexclass Ch, class Tr, class Az 
bool operator-—(const Ch", const basic stringzCh, Tr, A2£ ); 


templatexclass Ch, class Tr, class Az 
bool operator-—(const basic stringZCh, Tr, A2£, const Ch"); 





// és ugyanilyen deklarációk a !/-, 2, c, 27, és a cz számára 


Az összehasonlító operátorok nem tag függvények, így a konverziók mindkét operandusra 
ugyanúgy vonatkoznak (§11.2.3). A C stílusú karakterláncokat használó változatokra azért 
volt szükség, hogy a literálokkal való összehasonlítást hatékonyabbá tegyük: 


void Kconst stringk. name) 
( 
if (name --"Obelix" 1 I "Asterix"--name) (  / optimalizált -- használata 
VA 
, 
J 


20.3.9. Beszúrás 


Miután előállítottunk egy karakterláncot, sokféle műveletet végezhetünk vele. A karakter- 
lánc értékét módosító függvények közül talán a legfontosabb a hozzáfűzés, amely a karak- 
terlánc végén helyez el új karaktereket. Az általános beszúró műveletekre ritkábban van 
szükség: 


templatexclass Ch, class Tr - char. traiszCh:, class A - allocatorzZCh: 2 
class basic string f 
bublic: 

VA 

// karakterek hozzáadása CGthis)llengthO-1] után 


basic stringk operator4t—(const basic stringét 5); 
basic stringk operatort-(const Ch?" p); 

basic stringk operatort—(Ch c); 

void push back(Ch c); 


basic stringk abbend(const basic stringf 5); 
basic stringk abpbend(const basic stringé s, size tybe pos, size type n); 
basic stringk apbend(const Ch" p, size type n); 
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basic stringk append(const Ch? p); 
basic stringk append(size type n, Ch c); 
templatexclass In: basic stringk apbendd first, In last); 


// karakterek beszúrása (Gthis)lpos] elé 


basic stringék insert(size type pos, const basic string 5); 

basic string insert(size type pos, const basic stringk s, size tybe bos2, size type n); 
basic stringk insert(size type pos, const Ch" p, size type n); 

basic string insert(size type pos, const Ch?" p); 

basic string insert(size type pos, size type n, Ch c); 


// karakterek beszúrása p elé 


iterator insert(iterator p, Ch c); 
void insert(iterator p, size type n, Ch c); 
templatexclass In: void insert(iterator p, In first, In lasb; 
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Nagyjából ugyanazok a függvényváltozatok állnak rendelkezésünkre a beszúró és a hozzá- 


fűző eljárásoknál is, mint a konstruktorok és az értékadás esetében. 
A 47 operátor hagyományos jelölése a hozzáfűzésnek: 


string complete name(const stringét first name, const stringg family name) 
( 

string s - first name; 

S4ETL 

s 47 family name; 

return s; 


A karakterlánc végéhez való hozzáfűzés jelentősen hatékonyabb lehet, mint a más pozíci- 
ókra való beszúrás: 


string complete nameXconst string first name, const stringkt family name) 
// szegényes algoritmus 
( 
string s - family name; 
s.insert(s.beginO," "; 
s.insert(0 first name); 
return s; 
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A beszúrás gyakran arra kényszeríti a szring-et, hogy lassú memóriaműveleteket végezzen 
és áthelyezzen néhány karaktert. 


Mivel a szíring osztályban is szerepel a push backO művelet (§16.3.5), a back inserter 
ugyanúgy használható string objektumokhoz, mint bármely általános tárolóhoz. 


20.3.10. Összefűzés 


A hozzáfűzés különleges változata az összefűzésnek (konkatenációnak). Az összefűzést 
— tehát egy karakterlánc előállítását úgy, hogy két másikat egymás után helyezünk — a 4 
operátor valósítja meg: 


templatecxclass Ch, class Tr, class Az 
basic stringZCh, Tr, A2 
operatort(const basic stringzCh, Tr,A2£, const basic stringZCh, Tr, A2£ ); 


templatecxclass Ch, class Tr, class Az 
basic stringZCh, Tr,A2 operatori (const Ch", const basic stringZCh, Tr, A2£ ); 


templatexclass Ch, class Tr, class Az 
basic stringzCh, Tr,A2 operator4(Ch, const basic stringZCh, Tr, A2£ ); 


templatecxclass Ch, class Tr, class Az 
basic stringzCh, Tr,A2 operator4(const basic stringZCh, Tr,A2£, const Ch"); 


templatexclass Ch, class Tr, class Az 
basic stringZCh, Tr,A2 operator4(const basic stringZCh, Tr, A2£, Ch); 


Szokás szerint, a t műveletet nem tag függvényként adjuk meg. A több paramétert haszná- 
ló sablonok esetében ez némi kellemetlenséget okoz, mert a sablonparamétereket meg kell 
ismételnünk. 


Másrészt az összetűzés használata egyszerű és kényelmes: 


string complete name3(const stringk first name, const stringk family name) 


( 


return first name 4 !! a family name; 


J 


Ez a kényelem megér egy kis futási idejű teljesítményveszteséget a complete nameO függ- 
vényhez viszonyítva. A complete name30 függvényben külön ideiglenes változóra 
(§11.3.2) van szükségünk. Véleményem szerint ez ritkán fontos, de azért érdemes tudnunk 
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róla, ha egy nagy ciklust írunk egy olyan programban, ahol figyelnünk kell a teljesítmény- 
re. Ilyenkor esetleg érdemes megszüntetnünk a függvényhívást a complete nameO hely- 
ben (inline) kifejtésével, az eredményként kapott karakterláncot így helyben építhetjük fel, 
alacsonyabb szintű műveletek segítségével (420.6[14D. 


20.3.11. Keresés 


Zavarba ejtő mennyiségben állnak rendelkezésünkre olyan függvények, melyekkel egy ka- 
rakterlánc részláncait kereshetjük meg: 


templatexclass Ch, class Tr - char. traiszCh:, class A - allocatorzCh: 2 
class basic string ( 
bublic: 

ZAB 


// részsorozat kerése (mint a searchO, §18.5.5) 


size type find(const basic stringé s, size type i — 0) const; 
size type find(const Ch" p, size type i, size type n) const; 
size type find(const Ch" p, size type i - 0) const; 

size type find(Ch c, size type i - 0) const; 


// részsorozat keresése visszafelé (mint a find endO, §18.5.5) 


size type rfind(const basic stringét s, size type i - nbos) const; 
size type rfind(const Ch" p, size type i, size type n) const; 
size type rfind(const Ch" p, size tybe i - npos) const; 

size type rfind(Ch c, size type i - npos) const; 


// karakter keresése (mint a find first of0O), §18.5.2 


size type find first of(const basic stringé s, size type i - 0) const; 
size type find first of(const Ch" p, size type i, size type n) const; 
size type find first of((const Ch" p, size type i - 0) const; 

size type find first o((Ch c, size type i - 0) const; 


// karakter keresése baraméter alapján visszafelé 

size type find last of(const basic stringé s, size type i - npos) const; 
size type find last of(const Ch? p, size type i, size type n) const; 
size type find last of(const Ch" p, size type i - npos) const; 

size type find last o((Ch c, size type i - nbos) const; 


// paraméterben nem szereplő karakter keresése 
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size type find first not of(const basic string s, size type i - 0) const; 
size type find first not of(const Ch" p, size type i, size type n) const; 
size type find first not of(const Ch" p, size type i - 0) const; 

size type find first not o((Ch c, size type i - 0) const; 


// paraméterben nem szereplő karakter keresése visszafelé 


size type find last not of(const basic stringé s, size type i — nbpos) const; 
size type find last not of(const Ch" p, size type i, size type n) const; 
size type find last not of(const Ch" p, size type i - npos) const; 
size type find last not of((Ch c, size type i - npos) const; 
1 ss 

j; 














Az összes fenti függvény const. Tehát arra használhatók, hogy valamilyen célból megkeres- 
senek egy részláncot, de maguk nem változtatják meg azt a karakterláncot, amelyre alkal- 
maztuk azokat. 


A basic string::find műveletek jelentését úgy érthetjük meg legjobban, ha megértjük a ve- 
lük egyenértékű általános algoritmusokat: 


void JO 
( 
string s - "accdcde"; 
typedef ST; 
string::size type i1 -— s find("cd"; //i1 — 2 s[2]--c ££ 5[3]/--d" 
string::size type i2 - s.rfindC cd"); 12 - 4 s[l4l-- c ££ s[51-— d! 
string::size type i3 - s find first of("cd); [13-01 5[1]—-— c 
string::size type i4 - s find last of(cd"; [/14- 5 s[5]-—- d 
string::size type i5 -— s find first not of("cd"); //15 7-0 s[0Jr-c" ££ s[0]/- d" 
string::size type i6 -— s. find last not of(( "cd"; // 16 - 6 s[6]/-c" ££ s[6]//- d! 
j 


Ha a findOŐ függvények nem találják meg, amit kellene, npos értéket adnak vissza, amely ér- 
vénytelen karakterpozíciót jelent. Ha az npbpos értéket karakterpozícióként használjuk, 
range error kivételt kapunk (§20.3.59. Figyeljünk rá, hogy a findO eredménye unsigned érték. 


20.3.12. Csere 


Miután meghatároztunk egy karakterpozíciót a karakterláncban, az indexelés segítségével 
az egyes karaktereket módosíthatjuk, de a reblaceO művelet felhasználásával lecserélhe- 
tünk teljes részláncokat is: 
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templatexcilass Ch, class Tr - char. traitsZCh:, class A - allocatorzCh: 5 
class basic string ( 
bublic: 


/ 


[e Cthis)lij, Cthis)li--n] ( felcserélése más karakterekkel 


basic stringk replace(size type i, size type n, const basic stringét 5); 
basic stringk replace(size type i, size type n, 


const basic stringét s, size type i2, size type n29; 


basic stringk replace(size type i, size type n, const Ch" p, size tybe n29; 
basic stringk replace(size type i, size type n, const Ch" p); 
basic stringk replace(size type i, size type n, size type n2, Ch c); 


basic stringk replace(iterator i, 
basic stringk replaceCiterator i, 
basic stringk replaceCiterator i, 
basic stringk replaceCiterator i, 


iterator i2, const basic stringét 5); 
iterator i2, const Ch? p, size type n); 
iterator i2, const Ch? p); 

iterator i2, size type n, Ch c); 


templatexclass In: basic stringk replace(iterator i, iterator i2, In j, In j29; 


// karakterek törlése a láncból ("csere semmire") 


basic stringk erase(size type i — O, size type n - npos); 


iterator erase(iterator 1); 


iterator erase(iterator first, iterator last); 
void clearO; // az összes karakter törlése 


1/4498 


Az új karakterek számának nem kell megegyeznie a karakterláncban eddig szereplő karak- 


terek számával. A karakterlánc mérete úgy változik, hogy az új részlánc pontosan elférjen 
benne. Valójában az erase0 függvény sem csinál mást, mint hogy a megadott részláncot 
üres karakterláncra cseréli és az eredeti karakterlánc méretét megfelelően módosítja: 


void JO 


( 


J 


string s - "Márpedig ez működik, ha elhiszed, ha nem."; 


s.erase(0,8); 


// a "Márpedig " törlése 


s.replacecs find("ez"), 2, "Csak akkor"); 
s.replacecs findC", ha nem"), 8,""); // törlés "" behelyettesítésével 


Az erase0 függvény egyszerű, paraméter nélküli meghívása a teljes karakterláncot üres ka- 
rakterlánccá alakítja. Ezt a műveletet az általános tárolók esetében a clearO függvény való- 
sítja meg (§16.3.069. 
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A replace0 függvény változatai az értékadás változataihoz igazodnak, hiszen a replaceO va- 
lójában nem más, mint értékadás egy részláncnak. 


20.3.13. Részláncok 


A substrÓ függvény lehetővé teszi, hogy kiválasszunk egy részláncot, amelyet kezdőpozí- 
ciójával és hosszával adunk meg: 


templatexclass Ch, class Tr - char. traiszCh:, class A - allocatorzCh: 2 
class basic string f( 
bublic: 

2 as 


// részlánc címzése 


basic string substr(size type i - O, size tybe n - npos) const; 
VUK 
j; 


A substrO függvény egyszerű módszert biztosít a karakterlánc egy részletének kiolvasásá- 
ra. Ebből a szemszögből a párja a replace0 függvény, mellyel felülírhatjuk a karakterlánc 
egy részét. Mindkét függvénynek a kezdőpozíciót és a részlánc hosszát kell megadnunk. 
A findO segítségével viszont már érték szerint is megtalálhatunk részláncokat, így ez a függ- 
vénycsopotrt lehetővé teszi, hogy definiáljunk egy részlánc-osztályt, amelyet írni és olvasni 
is tudunk: 


templatezclass Ch: class Basic substring f 
public: 
typedef typename basic stringzZCh:::size type size type; 


Basic substring(basic stringcCh:d s, size type i, size tybe n); 77 sliJ..sli3n-17 
Basic substring(basic stringZCh:£ s, const basic stringcCh:£ s29; // 52 az s-ben 
Basic substring(basic stringcCh:g s, const Ch? p); /?p az s-ben 
Basic substringk operator-(const basic stringcCh:£); // írás "ps-be 


Basic substringk operator-(const Basic substringZCh:£ ); 
Basic substringk operator-(const Ch"); 
Basic substringk operator-(Ch); 


operator basic stringZCh:0 const; // olvasás "ps-be 
operator const Ch?" O const; /a c strO használata 
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brivate: 
basic stringZCh5? ps; 
size type pos; 
size type n; 


J; 


Az osztály megvalósítása is nagyon egyszerű: 


templatezclass Ch: 

Basic substringZCh:::Basic substring(basic stringcCh:£ s, const basic stringcCh:£ s2) 
: ps(ks), n(s2.lengthO) 

( 
bos - s find(s29; 

2 


J 
templatezclass Ch: 
Basic substringcCh:£ Basic substringZCh:::operator—(const basic stringZCh:£ s) 


( 
bps-ereplace(pos,n, 59; // írás "ps-be 
return "this; 


j 


templatezclass Ch: Basic substringzCh:::operator basic stringZCh:0 const 


( 
return basic stringZCh:(Cps bos n); // másolás "ps-be 
2 


B 4 
Ha s2 nem található meg az s karakterláncban, pos értéke npos lesz, így ha egy ilyen rész- 
láncot próbálunk meg írni vagy olvasni, range error kivételt kapunk (§20.3.59. 


A Basic substring osztály a következő formában használható: 


typedef Basic substring£char: Substring; 


void JO 
( 


string s - "Mary had a little lamb"; 

Substring(Cs, " lamb") - "fun"; 

Substring(Cs, "a little") - "no"; 

string s2 - "Joe" 4 Substring(s,s findC ",string::nbos); 


Természetesen sokkal érdekesebb feladatokat is elvégezhetnénk, ha a Substring osztály 
mintaillesztést is tudna végezni (§20.6[7D. 
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20.3.14. Méret és kapacitás 


A memóriakezeléssel kapcsolatos kérdéseket a szring nagyjából ugyanúgy kezeli, mint 
a vector (§16.3.8): 


templatexclass Ch, class Tr - char. traiszCh:, class A - allocatorZCh: 5 
class basic string f( 


public: 
VE 
// méret, kapacitás stb. (mint a §16.3.8 pontban) 
size type sizeO const; // karakterek száma (f20.3.4) 
size type max sizeO const; // a legnagyobb lehetséges karakterlánc 


size type lengthO const (f return sizeO); ) 
bool emptyO const f return sizeO0—-0; ) 


void resize(size type n, Ch c); 
void resize(size type n) f resize(rn, ChO),; ) 


size type capacityO const; // mint a vector, §16.3.§ 
void reserve(size type res arg - 09; // mint a vector, f16.3.8 


allocator. type get allocatorO const; 


ői 


A reverse(res arg) függvény length error kivételt vált ki, ha res arg2max sizeO. 


20.3.15. KI- és bemeneti műveletek 


A string osztály egyik legfontosabb felhasználási területe, hogy bemeneti műveletek célja, 
illetve kimeneti műveletek forrása legyen. A basic string [/O operátorait a Cstring: (és nem 
az Ciostream?) tartalmazza: 


templatecclass Ch, class Tr, class Az 
basic istreamzCh,Tr-k operator:P(basic istreamzCh,Tr:£k, basic stringzCh, Tr, A2£ ); 


templatexclass Ch, class Tr, class Az 
basic ostreamzZCh,Tr-:£ operatorsz(basic ostreamcCh,Tr:£,const 
basic stringcCh, Tr, A2£ ); 


templatexclass Ch, class Tr, class Az 
basic istreamzCh,Tr-£k getline(basic istreamzCh,Ir:k, basic stringzcCh, Tr,A2£, Ch eoD; 


templatexclass Ch, class Tr, class Az 
basic istreamzCh,Tr-k getline(basic istreamzCh,Tr:£k, basic stringzCh, Ir, A2£ ); 
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A cc a karakterláncot egy kimeneti adatfolyamra Costream, §21.2.1) írja, míg a 32 operátor 
egy üreshely karakterekkel határolt szót olvas be a karakterláncba egy bemeneti adatfo- 
lyamról (§3.6, §21.3.19. A szó előtti szóköz, tabulátor, újsor stb. karaktereket egyszerűen át- 
ugorja és a szó után következő ilyen karakterek sem kerülnek bele a karakterláncba. 


A getlineO függvény meghívásával egy teljes, eol karakterrel lezárt sort olvashatunk be a ka- 
rakterláncba, a karakterlánc mérete pedig úgy növekszik, hogy a sor elférjen benne (43.09. 
Ha nem adjuk meg az eol paramétert, a függvény az Mi! újsor karaktert használja. A sorzá- 
ró karaktert beolvassa az adatfolyamról, de a karakterláncba nem kerül be. Mivel a string 
mérete úgy változik, hogy a beolvasott sor elférjen benne, nincs szükség arra, hogy a lezá- 
ró karaktert az adatfolyamban hagyjuk vagy visszaadjuk a beolvasott karakterek számát 
a hívónak. A karaktertömbök esetében a get0 és a getlineO kénytelen volt ilyen, ellenőr- 
zést segítő megoldásokat alkalmazni (421.3.49. 


20.3.16. Felcserélés 


Ugyanúgy, mint a vector-nál (§416.3.9), a svapO függvényből a karakterláncokhoz is sokkal 
hatékonyabb specializációt készíthetünk, mint az általános algoritmus: 


templatexclass Ch, class Tr, class A: 
void swap(basic stringZCh, Tr,A2£, basic stringZCh, Tr, A2£); 


20.4. A C standard könyvtára 


A C334 standard könyvtára örökölte a C stílusú karakterláncok kezelésével foglalkozó függ- 
vényeket. Ebben a pontban felsorolunk néhányat a legfontosabb, C karakterláncokat keze- 
lő függvények közül. A leírás egyáltalán nem terjed ki mindre; ha részletes információkat 
szeretnénk megtudni, nézzük meg fejlesztőrendszerünk kézikönyvét. Legyünk óvatosak 
ezen függvények használatakor, mert a könyvtárak készítői gyakran saját, nem szabványos 
függvényeket adnak meg a szabványos fejállományokban, így nehéz megállapítani, hogy 
melyek a minden rendszerben elérhető függvények. 


A C standard könyvtárának lehetőségeit leíró fejállományok listáját a §16.1.2 pontban adtuk 
meg. A memóriakezelő függvényekkel a §19.4.6 pontban foglalkozunk, a C ki- és bemene- 
ti függvényeivel a §21.8 részben, a C matematikai könyvtárával pedig a §22.3 pontban. 
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A program indításával és befejezésével kapcsolatos függvényeket a §3.2 és a §9.4.1.1 pont- 
ban mutattuk be, míg a meghatározatlan függvényparaméterek beolvasását segítő függvé- 
nyeket a §7.6 pont tárgyalta. Azon C stílusú függvények, melyek a széles karaktereket keze- 
lik, a ccwchar: és a cwchar.h: fejállományban találhatók. 


20.4.1. C stílusú karakterláncok 


A C stílusú karakterláncok kezelésével foglalkozó függvények a cstring.h: és a ccstring: 
fejállományban találhatók: 


char" strepy(char? p, const char" ag); // másolás g-ból p-be (a lezáróval együtt) 
char" strcat(char? p, const char? 9); // hozzáfűzés a-ból p-be (a lezáróval együtt) 
char" strncpy(char? p, const char"? g, int n); // n karakter másolása g-ból p-be 

char" strncat(char? p, const char" g, int n); // n karakter hozzáfűzése ag-ból p-be 
size t strlen(Cconst char" p); // p hossza (a lezáró nélkül) 

int stremp(const char? p, const char? 9); // p és g összehasonlítása 


int strncmp(const char? p, const char?" g, intn);  // az első n karakter összehasonlítása 


char" strchr(char" p, int c); // az első c keresése p-ben 
const char" strchr(const char? p, int c); 

char" strrchr(char" p, int c); // az utolsó c keresése p-ben 
const char"? strrchr(const char? p, int c); 

char" strstrcchar? p, const char? 9); // az első g keresése p-ben 


const char" strstr(const char? p, const char? 9); 


char" strpbrk(char? p, const char? 9); // a első karakterének keresése p-ben 
const char? strpbrk(const char? p, const char" ag); 
size t strspn(const char? p, const char" a); // p karaktereinek száma az első, 
// g-ban szereplő karakter előtt 
size t strcspn(const char? p, const char? 9); // p karaktereinek száma az első, g-ban 


nem szereplő karakter előtt 


A megadott mutatókat a függvények nem-nulláknak feltételezik, azoknak a char tömbök- 
nek pedig, melyekre a mutatók mutatnak, 0 karakterrel lezárt sorozatoknak kell lenniük. 
Az strn függvények 0 karakterekkel töltik fel a hiányzó területet, ha nincs n darab feldol- 
gozandó karakter. A karakterlánc-összehasonlítások nullát adnak vissza, ha a két karakter- 
lánc egyenlő; negatív számot, ha az első paraméter ábécésorrendben előbb következik, 
mint a második; fordított esetben pedig pozitív számot. 
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Természetesen a C nem biztosít túlterhelt függvénypárokat, a Ct-4-ban azonban szükség 
van ezekre a const biztonságos megvalósításához: 


void fconst char? pcc, char? pc) [/Ctt 
( 


kstrchr(pcc, a!) — bt // hiba: const char-nak nem adhatunk értéket 


tstrchr(pc, a) - b; // rendben, bár nem tökéletes: lehet, hogy pc-ben nincs a" 


J 


A C44 strchrÓ függvénye nem engedi meg, hogy const karakterláncba írjunk, egy C prog- 
ram azonban , kihasználhatja" a C-beli strchrO gyengébb típusellenőrzését: 


char? strchi(const char" p, int c); /5 C standard könyutárbeli függvény, nem C44 ?/ 


void g(const char? pcc, char? pc) / CG, a C44 nem fordítja le "/ 


t 
tstrchr(pcc, a!) - b; /£ const átalakítása nem const-tá: C-ben jó, C44-ban hiba "/ 
tstrchr(pc, a) - b; /5 jó C-ben és C44-ban is "/ 


j 


Ha tehetjük, feltétlenül kerüljük a C stílusú karakterláncok használatát és használjuk helyet- 
tük a string osztályt. A C stílusú karakterláncok és a hozzájuk tartozó szabványos függvé- 
nyek segítségével nagyon hatékony programokat írhatunk, de még a gyakorlott C és Cr 
programozók is gyakran követnek el , buta kis hibákat" miközben ezekkel dolgoznak. Per- 
sze minden C44 programozó találkozni fog olyan régebbi programokkal, melyek ezeket 
a lehetőségeket használják. Íme egy haszontalan kis példa, amellyel a leggyakoribb függ- 
vényeket mutatjuk be: 


void fchar? p, char: gp) 


( 
if (P--9a) return; // a mutatók egyenértékűek 
if (strcemp(p,g)--0) f // a karakterlánc-értékek egyenértékűek 
int i -— strlen(p);  // a karakterek száma (a lezáró nélkül) 
4754 
j 
char bujt200/; 
strepy(bufp; // p másolása a buf-ba (a lezáróval együtt) 
// nem tökéletes, tűlcsordulhat 
strncpy(bufp, 200); // 200 karakter másolása p-ből a buf-ba 


// nem tökéletes; lehet, hogy nem másolja át a lezárót 
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A C stílusú karakterláncok ki- és bevitelét általában a printffüggvénycsalád segítségével va- 
lósítjuk meg (421.8). 


Az cstdlib.h: és a ccstdlib: fejállományban a standard könyvtár néhány olyan hasznos 
függvényt nyújt, melyekkel számértéket jelölő karakterláncokat alakíthatunk számmá: 


double atof(const char? p9; // p átalakítása double-lá 
int atoi(const char? p); // Pp átalakítása int-té 
long atolkcconst char" p); // p átalakítása long-gá 


A bevezető üreshely karaktereket ezek a függvények nem veszik figyelembe. Ha a karak- 
terlánc nem számot ábrázol, a visszatérési érték 0 lesz. (Az atoi(" hét") eredménye is 0) 
Ha a karakterlánc számot jelöl, de az nem ábrázolható az eredményként várt számtípusban, 
akkor az errno (§16.1.2, §22.3) változó értéke ERANGE lesz, a visszatérési érték pedig egy 
nagyon nagy vagy nagyon kicsi szám, a konvertált értéknek megfelelően. 


20.4.2. Karakterek osztályozása 


A cctype.h: és a Ccctybe: fejállományban a standard könyvtár olyan hasznos függvényeket 
kínál, melyek az ASCII, illetve a hasonló karakterkészletek karaktereit osztályozzák: 


int isalpbhaGin); // a..z1A..Z betűk, C-hez (§20.2.1, 621.7) 
int isubber(inD); //A..Z nagybetűk, C-hez (§20.2.1, §21.7) 
int islower(CinD); // 1a!..2 kisbetűk, C-hez (§20.2.1, §21.7) 


int isdigit(int); // tízes számrendszerű számok: "0".."9" 

int isxdigitGinb); // hexadecimális számok: "0... 9" vagy "a... f vagy JA... F" 
int isspace(in0); TT) Mt Nw kocsivissza, újsor, függőleges tabulátor 
int iscntriGinD; // vezérlőkarakter (ASCII O..31 és 127) 

int ispunctGin9; // központozás, a fentiek egyike sem tartozik bele 

int isalnum(inY9; — // isalphaO 1 isdigitŐ 

int isprint(int9; // nyomtatható karakterek: ascii ! "..—! 


int isgraphGny); // isalphaO 1 isdigitŐ l isbunctO 


int toupber(int c); . // c nagybetűs megfelelője 
int tolowerGCint c); . // c kisbetűs megfelelője 


A fentieket általában egyszerű kiolvasással valósítják meg, úgy, hogy a karaktert indexként 
használják egy táblában, amely a karakterek jellemzőit tárolja. Ezért az alábbi kifejezés 
amellett, hogy túlságosan hosszú és sok hibalehetőséget rejt magában (például egy EBCDIC 
karakterkészletet használó rendszerben nem alfabetikus karakterek is teljesítik a feltételt, 
nem is hatékony: 
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if(Caszckg cs-z) II (Aszc£kgcc-Z))( / betű 
KÜNÉS 


J 


Ezek a függvények egy int paramétert várnak, és az átadott egésznek vagy ábrázolhatónak 
kell lennie egy unsigned char típussal vagy az EOF értéknek kell lennie (ami általában 
a —D. Ez az értelmezés problémát jelenthet az olyan rendszerekben, ahol a c/Auar előjeles tí- 
pus (ásd: §20.6[11D. 


Ugyanilyen szerepű függvények rendelkezésre állnak széles karakterekre is, a Ccwtype: és 
a Cwtype.h: fejállományban. 


20.5. Tanácsok 


[1] 


[2] 
fől 


[4] 


[5] 
[6] 


[7] 


[8] 


[91 


[10] 


[11] 


A C stílusú függvények helyett lehetőleg használjuk a string osztály eljárásait. 
§20.4.1. 

A string lehet változó vagy tag, de bázisosztálynak nem való. §420.3, §25.2.1. 

A karakterláncokat érdemes érték szerint átadni és visszaadni, mert így a rend- 
szerre bízzuk a memóriakezelést. §20.3.6. 

A bejárók és a / / operátor helyett használjuk az at0 függvényt, ha tartományel- 
lenőrzésre van szükségünk. §420.3.2, §20.3.5. 

A bejárók és a / / operátor gyorsabb, mint az at0 függvény. §420.3.2, §20.3.5. 
Közvetve vagy közvetlenül, a részláncok olvasásához használjuk a szbstrO, 
írásukhoz a replaceO függvényt. §20.3.12, §20.3.13. 

Adott érték megkereséséhez egy karakterláncban használjuk a findŐO függvényt 
Cés ne írjunk saját ciklust erre a feladatra). §20.3.1. 

Ha hatékonyan akarunk egy karakterláncot karakterekkel bővíteni, használjuk 
a hozzáfűzés műveleteit. §20.3.9. 

Ha az idő nem létfontosságú szempont, a karakterbevitelre használjunk szring 
objektumokat. 420.3.1.5. 

Használjuk a string::npos értéket a , karakterlánc hátralévő részének" jelzésére. 
§20.55. 

Ha gyakran használunk egy alacsonyszintű szolgáltatást, akkor azt készítsük el 
a string osztályhoz, ne használjunk emiatt mindenhol alacsonyszintű adatszer- 
kezeteket. §20.3.10. 
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[12] Ha a string osztályt használjuk, valahol mindig kapjuk el a range error és 


out of range kivételeket. §20.3.5. 


[13] Figyeljünk rá, hogy ne adjunk át char" mutatót O értékkel egy karakterlánc- 


kezelő függvénynek. §20.3.7. 


[14] Ha nagyon nagy szükségünk van rá, a c strO függvény segítségével egy szíring 


objektumból előállíthatjuk a C stílusú karakterlánc megfelelőjét. 420.3.7. 


[15] Használjuk az isalphaO, isdigitO stb. függvényeket, ha a karaktereket osztályoz- 


nunk kell, ne írjunk saját ellenőrzéseket a karakterértékek alapján. §20.4.2. 


20.6. Gyakorlatok 


A fejezet feladatainak többségéhez a standard könyvtár bármely változatának forráskódjá- 
ban találhatunk megoldást, mielőtt azonban megnéznénk, hogy a könyvtár alkotói hogyan 
közelítették meg a problémát, próbáljunk saját megoldást keresni. 


L 


(2) Készítsünk egy függvényt, amely két siring objektumot vár paraméterként 
és egy újabb karakterláncot ad vissza, amelyben a két karakterlánc összetfűzése 
szerepel úgy, hogy közöttük egy pont áll. A /ile és a write karakterláncokból 
például a függvény a /ile.write eredményt állítsa elő. Oldjuk meg ugyanezt a fel- 
adatot C stílusú karakterláncokkal és a C lehetőségeinek (például a mallocO és 
az strlenŐ függvények) felhasználásával. Hasonlítsuk össze a két függvényt. 
Milyen fontos összehasonlítási szempontokat kell megvizsgálnunk? 

(2) Foglaljuk össze egy listában a vector és a basic string osztály közötti kü- 
lönbségeket. Mely különbségek igazán fontosak? 

(2) A karakterlánc-kezelő lehetőségek nem teljesen szabályosak. Egy karaktert 
(char) például értékül adhatunk egy karakterláncnak, de kezdeti értékadásra 
nem használhatjuk. Készítsünk egy listát ezekről a szabálytalanságokról. Melye- 
ket küszöbölhettük volna ki ezek közül anélkül, hogy a karakterláncok haszná- 
latát túlbonyolítottuk volna? Milyen más szabálytalanságokat eredményezne ez 
az átalakítás? 


. C1.5) A basic string osztálynak nagyon sok tagfüggvénye van. Melyeket emel- 


hetnénk ki az osztályból és tehetnénk nem tag függvénnyé ezek közül anélkül, 
hogy a hatékonyságot és kényelmes használhatóságot feladnánk? 


. G1.5) Írjuk meg a back inserterO (§19.2.4) azon változatát, amely a basic string 


osztállyal működik. 


. (C2) Fejezzük be a §20.3.13 pontban bemutatott Basic substring osztály megva- 


lósítását és építsük be ezt egy olyan Sfring típusba, amely túlterheli a () operá- 
tort a ,részlánca" jelentéssel, de egyébként ugyanúgy viselkedik, mint a string. 
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(2.5) Készítsünk egy findO függvényt, amely egy egyszerű szabályos (regulá- 
ris) kifejezés első előfordulását keresi meg egy string objektumban. A kifejezés- 
ben a ? egyetlen, tetszőleges karaktert jelent, a " akárhány olyan karaktert, 
amely a kifejezés további részére nem illeszthető, az /abc/ azon karakterek bár- 
melyikét, amely a megadott halmazban szerepel (esetünkben a, vagy b, vagy 0. 
A többi karakter önmagát ábrázolja. A find(Cs, "name: ") például egy olyan muta- 
tót ad vissza, amely a name: első előfordulására mutat, míg 

a find(s, InNlameC)") kifejezés azt a részláncot jelöli ki az s karakterláncban, 
amelynek elején a name vagy a Name szó szerepel, majd zárójelek között egy 
(esetleg üres) karaktersorozat. 


. (2.5) Gondolkodjunk el rajta, hogy az előbbi (420.6[7]), reguláris kifejezés- 


illesztő függvényünkből milyen lehetőségek hiányoznak még. Határozzuk meg 
és valósítsuk meg ezeket. Hasonlítsuk össze az általunk létrehozott függvény ki- 
fejezőképességét egy széles körben elterjedt reguláris kifejezés-illesztő kifejező- 
képességével. Hasonlítsuk össze a két eljárást hatékonyság szempontjából is. 


. (2.5) Egy reguláris kifejezés-könyvtár segítségével készítsünk mintaillesztő 


műveleteket egy String osztályban, amelyhez egy Substring osztály is tartozik. 
Képzeljünk el egy , ideális" osztályt az általános szöveg-feldolgozási feladatok 
elvégzéséhez. Legyen az osztály neve 7ext. Milyen lehetőségeket kell megvaló- 
sítanunk? Milyen korlátozásokat és költségeket kényszerítenek az osztályra az 
általunk elképzelt , ideális" műveletek? 


. C1.5) Határozzuk meg az isalphaO, isdigitO stb. függvények túlterheléseit úgy, 


hogy megfelelően működjenek char, unsigned char és signed char típusra is. 
(2.5) Készítsünk egy Siring osztályt, amelyet arra optimalizálunk, hogy nyolc 
karakternél rövidebb karakterláncokat kezeljen. Hasonlítsuk össze ennek haté- 
konyságát a §11.12 pont String osztályával, illetve a szabványos sztring osztállyal. 
Készíthető-e olyan karakterlánc osztály, amely egyesíti a nagyon rövid karakter- 
láncokra optimalizált és a tökéletesen általános változat előnyeit? 

(2) Mérjük le egy string másolásának hatékonyságát. Megfelelően optimalizált 
saját fejlesztőrendszerünk síring osztálya a másolásra? 

(2.5) Hasonlítsuk össze a 420.3.9 és a §20.3.10 pontban bemutatott három 
complete nameg függvény hatékonyságát. Próbáljuk elkészíteni 

a complete nameO függvény azon változatát, amely a lehető leggyorsabban fut. 
Jegyezzük fel azokat a hibákat, amelyeket a megvalósítás és tesztelés közben 
tapasztaltunk. 

(2.5) Képzeljük el, hogy rendszerünk legkényesebb művelete a közepes 
hosszúságú (5-25 karakteres) karakterláncok beolvasása a cin adatfolyamról. 
írjunk egy bemeneti függvényt, amely az ilyen karakterláncokat tudja beolvasni 
olyan gyorsan, ahogy csak el tudjuk képzelni. Dönthetünk úgy, hogy a függ- 
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vény felületének kényelmes használatát feláldozzuk a sebesség érdekében. Ha- 
sonlítsuk össze eljárásunk hatékonyságát a string osztály 2: operátorának haté- 
konyságával. 
. C1.5) Írjuk meg az itos(int) függvényt, amely a paraméterként megadott int 
érték string ábrázolását adja vissza. 
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, Csak azt kapod, amit látsz" 
(Brian Kernighan) 


Kimenet és bemenet s Kimeneti adatfolyamok e Beépített típusok kimenete e Felhaszná- 
lói típusok kimenete s Virtuális kimeneti függvények s Bemeneti adatfolyamok e Beépített 
típusok bemenete s Formázatlan bemenet e Adatfolyamok állapota e Felhasználói típusok 
bemenete s [/O kivételek s Adatfolyamok összekötése e Őrszemek s Egész és lebegő- 
pontos kimenet formázása s Mezők és igazítás " Módosítók e Szabványos módosítók s Fel- 
használói módosítók e Fájlfolyamok e Adatfolyamok lezárása s Karakterlánc-folyamok 
e Adatfolyamok és átmeneti tárolók s Helyi sajátosságok s Adatfolyam-visszahívások 
e printfO s Tanácsok s Gyakorlatok 


21.1. Bevezető 


Egy programozási nyelvben általános be- és kimeneti (input/output, I/O) rendszert megva- 
lósítani rendkívül nehéz. Régebben az [/O lehetőségek csak arra korlátozódtak, hogy né- 
hány beépített adattípust kezeljenek. A legegyszerűbbek kivételével azonban a C4- prog- 
ramok számos felhasználói típust is használnak, így e típusok ki- és bemenetét is meg kell 
oldani. Egy [/O rendszernek a rugalmasság és hatékonyság mellett egyszerűnek, kényel- 
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mesnek, biztonságosnak és mindenekfelett átfogónak kell lennie. Eddig még senki nem állt 
elő olyan megoldással, amellyel mindenki elégedett lenne, ezért lehetővé kell tennünk, 
hogy a felhasználó saját ki- és bemeneti eszközöket készíthessen, illetve a szabványos le- 
hetőségeket egyedi felhasználási területek kezelésével bővíthesse ki. 


A C44 olyan nyelv, melyben a felhasználó új típusokat adhat meg és e típusok használata 


ugyanolyan hatékony és kényelmes lehet, mint a beépített adattípusoké. Ezért logikus elvá- 
rás a Ct4 nyelv [/O szolgáltatásaitól, hogy C4-4 nyelven készüljenek és csak olyan eszkö- 
zöket használjanak, melyek minden programozó számára elérhetők. Az itt bemutatott, adat- 
folyam-bemenetet és -kimenetet kezelő lehetőségek az e követelmények kielégítésére tett 
erőfeszítések eredményei: 


§21.2 


421.3 


§21.4 


§21.5 


§21.6 


§21.7 


Kimenet: A kimenet alatt az alkalmazásprogramozó azt érti, hogy tetszőle- 
ges típusú (int, char?" vagy Employee record) objektumokból karakterso- 
rozatot állíthat elő. Ebben a pontban azokat a lehetőségeket ismertetjük, 
melyekkel a beépített és a felhasználói típusok kimenete megvalósítható. 
Bemenet. Azok az eszközök, melyekkel karaktereket, karakterláncokat 
vagy más (akár beépített, akár felhasználói) típusok értékeit beolvashatjuk. 
Formázás: A kimenet elrendezésével kapcsolatban gyakran különleges 
elvárásaink vannak. Az int értékeket például általában tízes számrend- 
szerben szeretjük kiírni, a mutatók hagyományos formája a hexadecimá- 
lis (tizenhatos számrendszetű) alak, a lebegőpontos számokat pedig 
megadott pontossággal kell megjeleníteni. Ez a rész a formázással és az 
azt segítő programozási eszközökkel foglalkozik. 

Fájlok és adatfolyamok: Alapértelmezés szerint minden C-- program 
használhatja a szabványos adatfolyamokat: a szabványos kimenetet 
(couD, a szabványos bemenetet (cin) és a hibakimenetet (cern. Ha más 
eszközöket vagy fájlokat akarunk használni, akkor adatfolyamokat kell 
létrehoznunk és ezeket hozzá kell kötnünk a megfelelő eszközhöz, illet- 
ve fájlhoz. Ez a rész a fájlok megnyitásának és bezárásának, illetve az 
adatfolyamok fájlokhoz és karakterláncokhoz való hozzákötésének mód- 
szereivel foglalkozik. 

Átmeneti tárolás: Hatékony ki- és bemenetet úgy lehet megvalósítani, ha 
átmeneti tárakat ( puffereket") használunk. A módszer alkalmazható 
mindkét oldalon, így az átmeneti tárból kiolvashatjuk és oda írhatjuk is 
az adatokat. Ebben a pontban az átmeneti tárolás (, pufferelés") alapmód- 
szereit mutatjuk be. 

Helyi sajátosságok: A locale objektum azt határozza meg, hogy a számo- 
kat általában milyen formában jelenítjük meg, milyen karaktereket tekin- 
tünk betűnek és így tovább. Tehát az adott kultúrára jellemző , specialitá- 
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sokat" foglalja össze. Az I/O rendszer automatikusan használja ezeket az 
információkat, így ez a rész csak nagy vonalakban foglalkozik a témával. 

421.8 C stílusú I/O: Itt a C cstdio.h: fejállományának printfO függvényét és a C 
könyvtárának a C4t- ciostream: könyvtárához fűződő viszonyát 
mutatjuk be. 


Ahhoz, hogy az adatfolyam-könyvtárat használjuk, nem kell értenünk a megvalósításához 
használt összes módszert, már csak azért sem, mert a különböző Ct--változatokban külön- 
böző módszereket alkalmazhatnak. Egy szép [/O rendszer megvalósítása azonban komoly 
kihívást jelent. Megírása közben számos olyan lehetőséggel megismerkedhetünk, amelyet 
más programozási és tervezési feladatok megoldásában is felhasználhatunk. Ezért nagyon 
fontos, hogy megismerjük azokat a módszereket, melyekkel egy ki- és bemeneti rendszer 
elkészíthető. 


Ebben a fejezetben csak addig a mélységig mutatjuk be az adatfolyamok bemeneti/kime- 
neti rendszerét, hogy pontosan megértsük annak szerkezetét, felhasználhassuk a leggyako- 
ribb [/D műveletek végrehajtásához, és ki tudjuk egészíteni úgy, hogy az általunk létreho- 
zott új típusokat is képes legyen kezelni. Ha szabványos vagy új típusú adatfolyamokat aka- 
runk használni, esetleg saját helyi sajátosságokat akarunk meghatározni, a könyvtár forrás- 
kódjára, jó rendszerleírásra, és működő példaprogramokra is szükségünk lesz az itt leírt in- 
formációkon kívül. 


Az adatfolyam [/O rendszer összetevőit az alábbi ábrával szemléltethetjük: 








ios base: 
helyi sajátosságoktól függet- 
len állapot 


basic ios25: sztk] 
helyi sajátosságoktól függő SSSSsésslgei 


állapot, adatfolyam-állapot locale: 


basic streambujfcz: 


átmeneti tárolás 























A formázási információk 
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karakterek átmeneti tárolása 

















basic iostreama5: 
formázás (cc, 55 stb.), 
létrehozás/felszámolás 











tényleges cél/forrás 
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A basic iostreamc? felől induló pontozott nyíl azt jelzi, hogy a basic ioszz egy virtuális 
bázisosztály, az egyszerű vonalak mutatókat ábrázolnak. Azon osztályok, melyek neve után 
a 5 jel szerepel, olyan sablonok, melyek paramétere egy karaktertípus és tartalmaznak egy 
locale objektumot is. 


Az adatfolyamok (streams) és az hozzájuk használt általános jelrendszer számos kommuni- 
kációs probléma megoldását lehetővé teszik. Adatfolyamokat használhatunk objektumok 
gépek közötti átvitelére (425.4.1), üzenetfolyamok titkosításához (421.10I22D, adattömörí- 
téshez, objektumok állandó (perzisztens) tárolásához és így tovább. Ennek ellenére az aláb- 
biakban csak az egyszerű, karakterközpontú ki- és bemenetet mutatjuk be. 


Az adatfolyam ki- és bemenethez kapcsolódó osztályok és sablonok deklarációját (melyek 
elég információt adnak ahhoz, hogy hivatkozzunk rájuk, de ahhoz nem, hogy műveleteket 
hajtsunk végre rajtuk), valamint a szabványos típus-meghatározásokat (typedef-ekeD az 
ciosfwd: fejállományban találhatjuk meg. Erre a fájlra néha szükségünk lesz, amikor más 
[/O fejállományokat — de nem az összeset — használni akarunk. 


21.2. Kimenet 


A beépített és a felhasználói típusok egységes és típusbiztos kezelése egyszerűen megvaló- 
sítható, ha túlterheljük a kimeneti függvényeket: 


but(cerr,"x - "); / cerr a hibaüzenetek kimeneti adatfolyama 
but(cerr,x); 
but(cerr, Ma); 


A paraméter típusa határozza meg, melyik butO függvény kerül meghívásra az adott hely- 
zetben. Ezt a megoldást sok nyelv alkalmazza, bár sok ismétlést kíván. Ha az , írd ki" mű- 
velet megvalósításához a c£ operátort terheljük túl, szebb jelölést kapunk és lehetőséget 
adunk a programozónak, hogy objektumok sorozatát egyetlen utasítással írja ki: 


cerr 2 Ix- "cz x cc NM; 


Ha x egy inttípusú változó, melynek értéke 723, akkor az előző parancs a szabványos hiba- 
kimeneti adatfolyamra (cerr) az alábbi szöveget írja ki (egy újsor karakterrel lezárva): 


x - 123 
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Ugyanakkor, ha xtípusa complex (422.5), értéke pedig (7,2.4), a kiírt szöveg az alábbi lesz: 


x - (1,2.4) 


Ez a stílus mindaddig működőképes, amíg x típusára a cc művelet definiált, márpedig a fel- 
használó könnyedén készíthet ilyen függvényt saját típusaihoz. 


Ha el akarjuk kerülni a kimeneti függvény használatából eredő kényelmetlen megfogalma- 
zást, mindenképpen szükségünk van egy kimeneti operátorra. De miért pont a c£ operá- 
tort válasszuk? Arra nincs lehetőségünk, hogy új nyelvi elemet vezessünk be (§411.2). Az ér- 
tékadó operátor használható lenne a ki- és a bemenet jelölésére is, de úgy tűnt, a legtöbb 
programozó különböző operátort szeretne használni a kimenethez és a bemenethez. Rá- 
adásul az - rossz irányba köt: a cout-a-b jelentése cout-(a-b), míg nekünk a (cout-a)-b 
értelmezésre lenne szükségünk (46.2). Próbálkoztam a c és a 5 operátor használatával is, de 
az emberek tudatában ez a két jel annyira a , kisebb, mint" és , nagyobb, mint" jelentéshez 
kapcsolódik, hogy az új [/O utasítások teljesen olvashatatlanok voltak. 


A c£ és a 55 operátort nem használjuk olyan gyakran a beépített típusokra, hogy ez prob- 
lémát okozzon programjaink olvashatóságában. Elég szimmetrikusak ahhoz, hogy jelké- 
pezzék a ,kimenet" és a bemenet" műveletet. Amikor ezeket az operátorokat ki- és beme- 
netre használjuk, a cc jelenti a kiírást, a 32 pedig a beolvasást. Azok, akik jobban szeretik 
a műszaki kifejezéseket, nevezhetik ezt a két műveletet sorrendben output-nak és inbut- 
nak, esetleg beszűrásnak és kinyerésnek (Ginserter, extractor). A c£ operátornak a preceden- 


cia sorrendben elfoglalt helye elég alacsony ahhoz, hogy zárójelezés nélkül lehetővé tegye 
a paraméterekben aritmetikai műveletek elvégzését: 


cout cz "atbrc-" cz atbrtc cz Mn; 


Ha azonban olyan műveletet akarunk használni, amely precedenciája alacsonyabban 
helyezkedik el, mint a cc operátor, akkor nem szabad elfelejtenünk a zárójeleket: 


cout cz "aMblc-" cc (amlc) cz Mk; 


A balra léptető operátor (§6.2.4) szintén használható kimeneti utasításban, de természete- 
sen ezt is zárójelek közé kell írnunk: 


cout c "accb-" cz (azcb) cz Mt 
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21.2.1. Kimeneti adatfolyamok 


Az ostream arra való, hogy tetszőleges típusú értékeket karakterek sorozatává alakítsunk. 
Ezután ezeket a karaktereket általában alacsonyszintű kimeneti műveletekkel írjuk ki. Sok- 
féle karakter létezik (§20.2) és ezeket egy-egy char. traits objektum jellemzi (420.2.19. Eb- 
ből következik, hogy az ostream egy bizonyos típusú karakterre , specializált" változata 
a basic ostream sablonnak: 


template Sclass Ch, class Tr - char. traiszCh: 2 
class std::basic ostream : virtual public basic ioszCh, Tr: f 
bublic: 

virtual -basic ostreamO; 


Ass 


J; 
A sablon és a hozzá tartozó műveletek az szid névtérben szerepelnek és az costream? fejál- 
lományból érhetők el, amely az ciostream: fejállomány kimenettel kapcsolatos részeit 
tartalmazza. 


A basic ostream paraméterei meghatározzák, hogy a megvalósítás milyen típusú karakte- 
reket használ, de nem rögzítik a kiírható objektumok típusát. Az egyszerű cAar típust és 
a széles karaktereket használó adatfolyamokat viszont minden változat közvetlenül támo- 
gatja: 


typedef basic ostreamá£char?: ostream; 
typedef basic ostreamZwchar. t2 wostream; 


Sok rendszerben a széles karakterek (wide character) írása olyan szinten optimalizálható 
a wostream osztály segítségével, amelyhez a kimeneti egységként bájtot használó adatfo- 
lyamok nehezen érhetnek fel. 


Lehetőség van olyan adatfolyamok meghatározására is, melyekben a fizikai ki- és bemene- 
tet nem karakterszinten valósítjuk meg, ezek az adattolyamok azonban meghaladják a stan- 
dard könyvtár hatókörét, így ebben a könyvben nem foglalkozunk velük (§21.10[15D. 


A basic ios bázisosztály az Ciosz fejállományban található. Ez kezeli a formázást (421.4), 
a helyi sajátosságokat (421.7) és az átmeneti tárak elérését (421.6) is. Az egységes jelölés- 
rendszer érdekében néhány típust is meghatároz: 
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template cclass Ch, class Tr - char. traitsZCh: 5 
class std::basic ios : public ios base ( 
bublic: 

typedef Ch char. type; 

typedef Tr traits type; 


typedef typename Tr::int type int type; // a karakter egész értékének típusa 
typedef typename Tr::pos type pos type; // pozíció az átmeneti tárban 
typedef typename Tr::off type off type; // eltolás az átmeneti tárban 


// ... lásd még §621.3.3, §21.3.7, 521.4.4, §21.6.3 és 621.7.1. ... 


A basic ios osztály letiltja a másoló konstruktort és az értékadó operátort. Ebből követke- 
zik, hogy az ostream és istream objektumok nem másolhatók. Ha egy adatfolyam célja 
megváltozik, kénytelenek vagyunk vagy az átmeneti tárat kicserélni (421.6.4) vagy mutató- 
kat használni (46.1.7). 


Az ios base bázisosztály olyan információkat és műveleteket tartalmaz, amelyek függetle- 
nek a használt karaktertípustól. (Ilyen például a lebegőpontos számok kimeneti pontossá- 
ga.) Ezért ez az osztály nem kell, hogy sablon legyen. 


Az ios base osztályban szereplő típus-meghatározásokon kívül az adatfolyam [/O könyvtár 
egy előjeles egész típust is használ, melynek neve streamsize és az egy [/D művelettel át- 
vitt karakterek számát, illetve az átmeneti tár méretét adhatjuk meg a segítségével. Emellett 
rendelkezésünkre áll a streamojfis, amely az adattolyamokban és az átmeneti tárakban va- 
ló eltolást (offse)) ábrázolja. 


Az ciostream? fejállomány több szabványos adatfolyamot is megad: 


ostream cout; // karakterek szabványos kimeneti adatfolyama 

ostream cerr; // hibaüzenetek szabványos, nem pufferelt kimeneti adatfolyama 
ostream clog; // hibaüzenetek szabványos kimeneti adatfolyama 

wostream wcoul; // a cout-nak megfelelő "széles" adatfolyam 

wostream wcerr; // a cerr-nek megfelelő "széles" adatfolyam 

wostream wclog; // a clog-nak megfelelő "széles" adatfolyam 


A cerr és a clog adatfolyamok ugyanarra a kimeneti eszközre mutatnak, a különbség köz- 
tük csak a használt átmeneti tár típusa. A cout ugyanarra az eszközre ír, mint a C stdout 
(421.8), míg a cerr és a clog ugyanarra, mint a C stderr. Ha szükség van rá, a programozó 
további adatfolyamokat is létrehozhat (§21.59. 
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21.2.2. Beépített típusok kimenete 


Az ostream osztály megadja a cc ( kimenet") operátort, amellyel a beépített típusok kiírá- 
sát végezhetjük el: 


template cclass Ch, class Tr - char. traitlsZCh: 5 
class basic ostream : virtual public basic ioszCh, Tr: ( 
bublic: 

V/ARNEA 


basic ostreamkg operatorsá(short n); 
basic ostreamkg operatorzá(int n); 
basic ostreamk operatorsá(long n); 


basic ostreamég operatorzs(unsigned short n); 
basic ostream£ operatorszá(unsigned int n); 
basic ostream£ operatorz(unsigned long n); 


basic ostream£k operatorszífloat f/; 
basic ostreamk operatorzc(double 9; 
basic ostreamk operatorss(long double f9; 


basic ostreamk operatorzá(bool n); 
basic ostreamé operatorss(const void? p); // mutatóérték kiírása 


basic ostreamk put(Ch c); // c kiírása 
basic ostream£g write(const Ch? p, streamsize n); // plol. pln-1] 


Ma: 


J; 


A putO és writeO függvények egyszerűen karaktereket írnak ki, így az erre a műveletre 
szolgáló c£ operátornak nem kell tagnak lennie. A karakter-operandust váró operatorzczO 
függvények a putO segítségével nem tagként készíthetők el: 


template cclass Ch, class Tr: 
basic ostreamZCh, Tr-£ operatorsz(basic ostreamzCh, Tr:£k, Ch); 
template cclass Ch, class Tr: 
basic ostreamzCh, Tr-£ operatorsc(basic ostreamzCh, Tr-£, char); 
template cclass Tr: 
basic ostreamcchar, Tr-£k operatorsz(basic ostreamáchar, Tr-:£, char); 
template cclass Tr: 
basic ostreamáchar, Tr:£k operatorsz(basic ostreamcáchar, Tr-:£k, signed char); 
template cclass Tr: 
basic ostreamcchar, Tr:£k operatorsz(basic ostreamáchar, Tr-k, unsigned char); 
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A cc a nullával lezárt karaktertömbök kiírásához is rendelkezésre áll: 


template cclass Ch, class Tr: 
basic ostreamáchar, Tr:£ operatorzz(basic ostreamzCh, Tr:k, const Ch"); 
template Sclass Ch, class Tr: 
basic ostreamcchar, Tr:k operatorzs(basic ostreamzCh, Tr:£k, const char"); 
template cclass Tr: 
basic ostreamcchar, Tr:£k operatorss(basic ostreamáchar, Tr:£, const char? ); 
template cclass Tr: 
basic ostreamcchar, Tr:£ operatorzs(basic ostreamáchar, Tr-£, const signed char"); 
template cclass Tr: 
basic ostreamcchar, Tr:k operatorzs(basic ostreamáchar, Tr-£k, const unsigned char"); 


A string-ek kimeneti operátorait a Cstring: tartalmazza (§20.3.15). 


Az operator 20 művelet egy referenciát ad vissza ugyanarra az ostream objektumra, amely- 
re meghívtuk, így azonnal alkalmazhatjuk rá a következő operator 20 műveletet: 


cerr 22 1x- " c2£ Xx; 


Itt x egy int, az utasítás jelentése pedig a következő: 


(cerr.operatorszz(Ix - ")).operatorzc(x); 


Fontos következmény, hogy amikor több elemet íratunk ki egyetlen kimeneti utasítással, 
azok a megfelelő sorrendben, balról jobbra haladva jelennek meg: 


void valkchar c) 


( 


cout c£ Vint( " Sz c Sz!) - " cz int(c) cz Mn; 


J 


int mainŐ 


( 
valCA?); 
valC 29); 
j 


Egy ASCII karaktereket használó rendszerben a fenti programrészlet eredménye a követ- 
kező lesz: 


intCA!) - 65 
int( 2) - 90 
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Megfigyelhetjük, hogy a karakterliterálok típusa char (§4.3.1), így a coutcc Za Z betűt fog- 
ja kiírni, nem annak int értékét, a 90-et. 


Ha logikai (booD értéket íratunk ki, az alapértelmezés szerint 0 vagy 1 formában jelenik 
meg. Ha ez nem megfelelő számunkra, beállíthatjuk az Cciomanip: fejállományban 
(421.4.6.2) meghatározott boolalpha formázásjelzőt, így a true vagy a false szöveg jelenik 
meg: 


int mainO 


cout CZ true cz ! ! cz false cz Mm; 
cout c£ boolalpha; // a true és false szimbolikus ábrázolása 
cout CZ true cz ! ! cz false cz Mm; 


j 


A kiírt szöveg: 


10 
true false 


Pontosabban fogalmazva a boolalpha tulajdonság azt biztosítja, hogy a bool értékeknek 


a helyi sajátosságoknak (ocale) megfelelő értékét kapjuk. Ha én megfelelően beállítom 
a locale-t (421.7), a következő eredményt kapom: 


10 
sandt falsk 


A lebegőpontos számok formázásáról, az egészek számrendszeréről stb. a §21.4. pontban 
lesz szó. 


Az ostream::operatorsá(const void") függvény egy mutató értékét jeleníti meg, az éppen 
használt számítógép felépítésének megfelelő formában: 


int mainO 
int i — 0; 
int? p - new int; 
cout cz "local " cz ki cc ", free store " 2£ p cc Mg; 


JA 
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Az eredmény az én gépemen a következő: 


local 0x7fffeadO, free store 0x500c 


Más rendszerek másképpen jeleníthetik meg a mutató értékét. 


21.2.3. Felhasználói típusok kimenete 
Képzeljük el az alábbi, felhasználói complex típust (§11.39: 


class complex ( 

bublic: 
double real0 const f return re; ) 
double imagO const f return im; ) 
Vég 

AA 


A cc operátort a következőképpen definiálhatjuk az új complex számára: 


ostreamk operators£(ostreamdés, const complexk 2) 


( 


return s ££ (" cz z.realÓ cc ,! cz z.iimagO cz ); 


J 


Ezután a c£ műveletet pontosan ugyanúgy használhatjuk saját típusunkra, mint a beépített 
típusokra: 


int mainŐ 


complex x(1,29; 
cout c Ix- "az x cc Mt 


J 


Az eredmény: 


x -— (1,2 


A felhasználói típusok kimeneti műveleteinek megvalósításához nem kell megváltoztat- 
nunk az ostream osztály deklarációját. Ez azért szerencsés, mert az ostream osztály az 
ciostream? fejállományban definiált, amit a felhasználók jobb ha nem változtatnak meg (er- 
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re nincs is lehetőségük). Az, hogy az ostream bővítését nem tettük lehetővé, védelmet nyújt 
az adatszerkezet véletlen módosítása ellen is, és lehetővé teszi, hogy anélkül változtassuk 
meg az ostream osztály megvalósítását, hogy a felhasználói programokra hatással lennénk. 


21.2.3.1. Virtuális kimeneti függvények 


Az ostream tagfüggvényei nem virtuálisak. Azok a kimeneti műveletek, melyeket egy prog- 
ramozó valósít meg, nem az osztály részei, így ezek sem lehetnek virtuálisak. Ennek egyik 
oka az, hogy az egyszerű műveletek esetében (például egyetlen karakter átmeneti tárba 
írása) így közel optimális sebességet érhetünk el. Ez olyan terület, ahol a futási idejű haté- 
konyság rendkívül fontos és szinte kötelező helyben kifejtett (inline) eljárásokat készíteni. 
A virtuális függvények használata it arra vonatkozik, hogy a lehető legnagyobb rugalmas- 
ságot biztosítsuk azon műveletek számára, melyek kifejezetten a átmeneti tár túlcsordulá- 
sával, illetve alulcsordulásával foglalkoznak (421.6.4. 


Ennek ellenére a programozók gyakran kívánnak megjeleníteni olyan objektumokat, me- 
lyeknek csak egy bázisosztálya ismert. Mivel a pontos típust nem ismerjük, a megfelelő ki- 
menetet nem állíthatjuk elő úgy, hogy egyszerűen minden új típushoz megadjuk a cc mű- 
veletet. Ehelyett készíthetünk egy virtuális kimeneti függvényt az absztrakt bázisosztályban: 


class My base f 
bublic: 
1/4b8 


virtual ostream£ put(ostreamd s) const - 0; // "this kiírása s-re 


J; 


ostreamk operatorss(ostreamd s, const My baseg r) 


( 


return r.put(5); . // a megfelelő put használata 


J 


Tehát a putO egy olyan virtuális függvény, amely biztosítja, hogy a megfelelő kimeneti mű- 
velet kerüljön végrehajtásra a c operátorban. 


Ennek felhasználásával a következő programrészletet írhatjuk. 


class Sometype : public My base f 
bublic: 
Ms 
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ostreamk put(ostreamd 5) const; // az igazi kimeneti függvény: My base::putO 
// felülírása 
j; 


void Kconst My basek r, Sometypedt s) // használjuk a c£ operátort a 
// megfelelő putÓ hívásához 
( 


cout CZ rez S; 


J 


Ezzel a virtuális putO függvény beépül az ostream osztály és a c művelet által biztosított 
keretbe. A módszer jól alkalmazható minden olyan esetben, amikor egy virtuális függvény- 
ként működő műveletre van szükségünk, de futási időben a második paraméter alapján 
akarunk választani. 


21.3. Bemenet 


A bemenetet a kimenethez nagyon hasonlóan kezelhetjük. Az istream osztály biztosítja 
a 55 bemeneti operátort néhány általános típushoz, a felhasználói típusokhoz pedig készít- 
hetünk egy-egy oberator:?0 függvényt. 


21.3.1. Bemeneti adatfolyamok 


A basic ostream (§21.2.1) osztállyal párhuzamosan az Cistream: fejállományban megtalál- 
hatjuk a basic istream osztályt, amely az Ciostream: bemenettel kapcsolatos részeit 
tartalmazza: 


template cclass Ch, class Tr - char. traitsZCh: 2 
class std::basic istream : virtual public basic ioszCh, Tr: (f 
bublic: 

virtual -basic istreamO; 


I sas 
ú 


A basic ios bázisosztályt a §21.2.1. pontban mutattuk be. 
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A cinés a wcin két szabványos bemeneti adatfolyam, melyeket az cCiostream: fejállomány ír le: 


typedef basic istreamáchar? istream; 
typedef basic istreamzwchar. t2 wistream; 


istream cin; // karakterek szabványos bemeneti adatfolyama 
wistream wcin; // szabványos bemeneti adatfolyam wchar. t részére 


A cin adatfolyam ugyanazt a forrást használja, mint a C szdin adatfolyama (§21.8). 


21.3.2. Beépített típusok bemenete 


A beépített típusokhoz az istream biztosítja a 22 operátort: 


template cclass Ch, class Tr - char. traitsZCh: 5 
class basic istream : virtual public basic ioszCh,Tr: ( 
bublic: 

Más 

// formázott bevitel: 


basic istreamét operator:r(shortk n); // olvasás n-be 
basic istreamé£ operator:x(intik n); 
basic istream£ operator:P(longk n); 


basic istreamdát operator:x(unsigned shortk u); // olvasás u-ba 
basic istream£k operator:x(unsigned intk u); 
basic istream£ operator:x(unsigned long£ u); 


basic istreamé£ operator:r(floatk f; // olvasás f-be 
basic istream£k operator:r(doublek f; 
basic istreamé£ operator:r(long doublek f; 


basic istream£ operator:r(boolg b); // olvasás b-be 
basic istream£ operator::(void"£k p); // mutatóérték olvasása p-be 
zést 


Az opberator:?( függvények a következő stílust követik: 


istreamé istream::operator:P(Ik tvar) // T egy típus, melyre az istream::operator:2 
// deklarált 
( 


// üreshely karaktereket átlépni, 
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// majd valahogyan beolvasni egy T típusú elemet "tvar-ba 
return "this; 


J 


Mivel a 5: átugorja az üreshely (whitespace) karaktereket, az ilyenekkel elválasztott egé- 
szeket az alábbi egyszerű ciklussal olvashatjuk be: 


int read ints(vectorsint-£ v)// feltölti v-t , visszatér a beolvasott egészek számával 


f 
inti — 0; 
while (izv.size0) kk cinszzuli)) itt; 
return í; 


J 


Ha a bemeneten egy nem egész érték jelenik meg, a bemeneti művelet hibába ütközik, így 
a ciklus is megszakad. Például ezt a bemenetet feltételezve: 


12345.6 78. 


a read intsO függvény öt egész számot fog beolvasni: 


12345 


A művelet után a bemeneten a következő beolvasható karakter a pont lesz. A nem látható 
üreshely (whitespace) karakterek meghatározása itt is ugyanaz, mint a szabványos C-ben 
(szóköz, tabulátor, újsor, függőleges tabulátorra illesztés, kocsivissza), és a ccctype? fejállo- 
mányban levő isspace0 függvénnyel ellenőrizhetők valamely karakterre (420.4.2). 


Az istream objektumok használatakor a leggyakoribb hiba, hogy a bemenet nem egészen 
abban a formátumban érkezik, mint amire felkészültünk, ezért a bemenet nem történik 
meg. Ezért mielőtt használni kezdenénk azokat az értékeket, melyeket reményeink szerint 
beolvastunk, ellenőriznünk kell a bemeneti adatfolyam állapotát (421.3.3), vagy kivételeket 
kell használnunk (§21.3.069. 


A bemenethez használt formátumot a helyi sajátosságok (locale) határozzák meg (421.79. 
Alapértelmezés szerint a logikai értékeket a 0 (hamis) és az 1 (igaz) érték jelzi, az egésze- 
ket tízes számrendszerben kell megadnunk, a lebegőpontos számok formája pedig olyan, 
ahogy a Cs programokban írhatjuk azokat. A basefield (§21.4.2) tulajdonság beállításával 
lehetőség van arra is, hogy a 0123 számot a 53 tízes számrendszerbeli szám oktális alakja- 
ként, a 0xffbemenetet pedig a 255 hexadecimális alakjaként értelmezzük. A mutatók beol- 
vasásához használt formátum teljesen az adott nyelvi változattól függ (nézzünk utána, saját 
fejlesztőrendszerünk hogyan működik). 
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Meglepő módon nincs olyan 5: tagfüggvény, mellyel egy karaktert olvashatnánk be. Ennek 
oka az, hogy a 22 operátor a karakterekhez a get karakter-beolvasó függvény (421.3.4) se- 
gítségével könnyen megvalósítható, így nem kell tagfüggvényként szerepelnie. Az adatfo- 
lyamokról saját karaktertípusaiknak megfelelő karaktereket olvashatunk be. Ha ez a karak- 
tertípus a char, akkor beolvashatunk signed char és unsigned char típusú adatot is: 


templatexclass Ch, class Tr: 
basic istreamZCh Tr-£ operator:P(basic istreamzCh Tr:k, Ch ); 


templatezclass Tr: 
basic istreamzchar,Tr:£ operator:P(basic istreamáchar,ITr-:£k, unsigned char£ ); 


templatexclass Tr: 
basic istreamáchar, Tr: operator:?(basic istreamáchar,ITr-:£k, signed char ); 


A felhasználó szempontjából teljesen mindegy, hogy a 5: tagfüggvény vagy önálló eljárás-e. 


A többi 55 operátorhoz hasonlóan ezek a függvények is először átugorják a bevezető 
üreshely karaktereket: 


void JO 

( 
char c; 
cin 55 c; 


Ms 


j 


Ez a kódrészlet az első nem üreshely karaktert a cin adatfolyamból a c változóba helyezi. 


A beolvasás célja lehet karaktertömb is: 


templatexcilass Ch, class Tr: 

basic istreamZCh Tr-£ operator:P(basic istreamzCh, Tr:£k, Ch"); 
templatezclass Tr: 

basic istreamcchar,Tr:£ operator:?(basic istreamáchar, Ir-£, unsigned char? ); 
templatexclass Tr: 

basic istreamcchar, Ir:£ operator:P(basic istreamáchar,Tr-:£k, signed char"); 


Ezek a műveletek is eldobják a bevezető üreshely karaktereket, majd addig olvasnak, amíg 
egy üreshely karakter vagy fájlvége jel nem következik, végül a karaktertömb végére egy 0 
karaktert írnak. Természetesen ez a megoldás alkalmat ad a túlcsordulásra, így érdemesebb 
inkább egy síring objektumba (420.3.15) helyezni a beolvasott adatokat. Ha mégis az előbbi 
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megoldást választjuk, rögzítsük, hogy legfeljebb hány karaktert akarunk beolvasni a 55 ope- 
rátor segítségével. Az is.width(n) függvényhívással azt határozzuk meg, hogy a következő, 
is bemeneti adatfolyamon végrehajtott 55 művelet legfeljebb n-17 karaktert olvashat be: 


void g0 


( 
char ulálj; 


cin. width(4); 
cin 55 v; 
cout c£ !y — " cz v cz endl; 


J 


Ez a programrészlet legfeljebb 3 karaktert olvas be a v változóba és a végén elhelyezi a 0 
karaktert. 


Egy istream esetében a widthO által beállított érték csak az utána következő 25 műveletre 
van hatással, és arra is csak akkor, ha a céltípus egy tömb. 


21.3.3. Az adatfolyam állapota 


Minden adatfolyam (az istream és az ostream is) rendelkezik valamilyen állapottal (state). 
A hibákat és a szokatlan állapotokat ezen állapotérték megfelelő beállításával és lekérdezé- 
sével kezelhetjük. 


Az adatfolyam-állapot (stream state) fogalmát a basic istream bázisosztálya, a basic ios írja 
le az Ciosz fejállományban: 


template cclass Ch, class Tr - char. traitsZCh: 5 
class basic ios : public ios base f 
bublic: 

Mész 


bool goodO const; 
bool eofO const; 
bool fail0 const; 
bool badO const; 


iostate rdstate0 const; 
void clear(iostate f - goodbiV); 
void setstate(iostate f) ( clear(rdstateO ID; ) 


// a következő művelet sikerülhet 

// fájlvége következett be 

// a következő művelet sikertelen lesz 
// az adatfolyam sérült 


// io állapotjelző lekérdezése 
// io állapotjelző beállítása 
// az f io állopotjelző beállítása 
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operator void? const; // nemnulla, ha !failO 
bool operator! const ( return fail0; ) 


Mata 
J; 


Ha az állapot goodO, a megelőző bemeneti művelet sikeres volt. Ilyenkor a következő be- 
meneti művelet helyes végrehajtására is van esély, ellenkező esetben viszont az biztosan 
nem lesz hibátlan. Ha egy olyan adatfolyamon próbálunk meg bemeneti műveletet végre- 
hajtani, amely nem goodO állapotban van, akkor semmi sem történik. Ha megpróbálunk a v 
változóba értéket beolvasni, de a bemeneti művelet sikertelen, v értékének nem szabad 
megváltoznia. (Ha v olyan típusú, amit az istream és az ostream tagfüggvényei kezelnek, 
biztosan megmarad az értéke.) A fail0 és a badO állapot közötti különbség igen kicsi. Ha 
az állapot fail0, de nem badO, akkor az adatfolyam érvénytelenné vált, de nem vesztek el 
karakterek. Ha badO állapotba kerültünk, már nem reménykedhetünk. 


Az adatfolyam állapotát jelzők (jelzőbitek, flag-ek) határozzák meg. Az adatfolyamok álla- 
potát kifejező legtöbb konstanshoz hasonlóan ezeket is a basic ios bázisosztálya, az 
ios base írja le: 


class ios base f( 
bublic: 
lesse 


tybedefimplementation defined2 iostate; 

static const iostate badbit, // az adatfolyam sérült 
eofbit, — // fájlvége következett be 
Jfailbit,  // a következő művelet sikertelen lesz 
goodbit; // goodbit--O 


ve 


J; 


Az [/O állapot jelzőbitjeit közvetlenül módosíthatjuk: 


void JO 
( 


ios base::iostate s - cin.rdstateO;  — //iostate bitek halmazával tér vissza 


if (s k ios base::badbit f 
// cin karakterek elveszhettek 
37 
I essek 
cin.setstate(ios base::failbiv); 


Mb 
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Ha az adatfolyamot feltételként használjuk, annak állapotát az operator void"0 vagy az ope- 
rator /O függvénnyel vizsgálhatjuk meg. A vizsgálat csak akkor lesz sikeres, ha az állapot 
J[fail0 (a void"0 esetében), illetve fail0 (a 10 esetében). Egy általános másoló eljárást pél- 
dául az alábbi formában írhatunk meg. 


templatecxciass T- void iocopy(istreamd is, ostreamdéz os) 


( 
T buj; 
while (isz2buj) os cz buf cz MG; 


J 


Az isz-zbufművelet egy referenciát ad vissza, amely az is adatfolyamra hivatkozik, a vizsgá- 
latot pedig az is::operator void" művelet végzi: 


void f(istreamdg il, istreamd i2, istreamd i3, istroeamk i4) 

( 
iocopyccomplex:(i1,cou); // komplex számok másolása 
iocopyzdoubler(i2,couD);  // kétszeres pontosságú lebegőpontos számok másolása 
iocopyccharo(i3,couD); // karakterek másolása 
iocopysstring-x(i4,cou; — // üreshelyekkel elválasztott szavak másolása 


J 


21.3.4. Karakterek beolvasása 


A 55 operátor formázott bemenetre szolgál, tehát adott típusú és adott formátumú objektumok 
beolvasására. Ha erre nincs szükségünk és inkább valóban karakterekként akarjuk beolvasni 
a karaktereket, hogy később mi dolgozzuk fel azokat, használjuk a get függvényeket: 


template cclass Ch, class Tr - char. traitsZCh: 5 
class basic istream : virtual public basic ioszCh, Tr: ( 


bublic: 
Ms 
// formázatlan bemenet 
streamsize gcountO const; // a legutóbbi get0 által beolvasott karakterek száma 
int type getO; // egy Ch (vagy Tr::eofO) beolvasása 
basic istroeam£k get((Chk c); // egy Ch olvasása c-be 
basic istreamdt get(Ch" p, streamsize n); // újsor a lezárójel 


basic istreamk get(Ch" p, streamsize n, Ch term); 
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basic istreamk getline(Ch? p, streamsize n); // újsor a lezárójel 
basic istreamk getlinel(Ch" p, streamsize n, Ch term); 


basic istream£ ignore(streamsize n — 1, int type t -— Tr::eofO); 
basic istream£ read(Ch" p, streamsize n); // legfeljebb n karakter beolvasása 


Sdús 


Ezek mellett a cszring: fejállomány biztosítja a getlineO függvényt is, amely a szabványos 
string-ek (420.3.15) beolvasására használható. 


A getŐ és a getline0 függvények ugyanúgy kezelik az üreshely karaktereket, mint bármely 
más karaktert. Kifejezetten olyan adatok beolvasására szolgálnak, ahol nem számít a beol- 
vasott karakterek jelentése. 


Az istream::get(chark ) függvény egyetlen karaktert olvas be paraméterébe. Egy karakte- 
renként másoló programot például a következőképpen írhatunk meg. 


int mainŐ 


( 

char c; 

whileC(cin.get(c)) cout.but(c); 
2 


Fj 
A háromparaméterű s.get(p,n, term) legfeljebb n-7 karaktert olvas be a D/O7, . . . , pín-2/ tömb- 
be. A get0 az átmeneti tárban mindenképpen elhelyez egy 0 karaktert a beolvasott karak- 
terek után, így a b mutatónak egy legalább n karakter méretű tömbre kell mutatnia. A har- 
madik paraméter (term) az olvasást lezáró karaktert határozza meg. A háromparaméterű 
getO leggyakoribb felhasználási módja az, hogy beolvasunk egy , sort" egy rögzített méretű 
tárba és később innen használjuk fel karaktereit: 


void JO 
( 
char bujt100/; 
cin 22 buf; // gyanús: túlcsordulhat 
cin.get(buf, 100,Mn)); // biztonságos 
Ússes 


Ha a getO megtalálja a lezáró karaktert, az adatfolyamban hagyja, tehát a következő beme- 
neti művelet ezt a karaktert kapja meg elsőként. Soha ne hívjuk meg újra a getŐ függvényt 
a lezáró karakter eltávolítása nélkül. Ha egy getO vagy getlineO függvény egyetlen karaktert 
sem olvas és távolít el az adatfolyamról meghívódik setstate(failbit), így a következő beol- 
vasások sikertelenek lesznek (vagy kivétel váltódik ki, 21.3.069. 
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void subtle error 
char bujfT256]; 


while (cin) ( 
cin.get(buf,2569; // a sor beolvasása 
cout cz buf: // a sor kiírása. 
// Hoppá: elfelejtettük eltávolítani cin-ről Nn-t, a következő getO sikertelen lesz 


Ez a példa jól szemlélteti, miért érdemes a getO helyett a getline0 függvényt használnunk. 
A getline0 ugyanis pontosan úgy működik, mint a megfelelő get, de a lezáró karaktert is 
eltávolítja az adattolyamból: 


void JO 
í 


char word/MAX WORDJIMAX LINE]; // MAX. WORD darab tömb, 
// mindegyik MAX. LINE karaktert tartalmaz 


inti — 0; 
whileCcin.getline(wordfitt/, MAX LINE, Nn) kk izMAX WORD); 
V0eat 


J 


Ha nem a hatékonyság a legfontosabb, érdemes sztring (§3.6, §20.3.15) objektumba olvas- 
nunk, mert azzal elkerülhetjük a leggyakoribb túlcsordulási, illetve helyfoglalási problémá- 
kat. A getO), a getlineO és a readO függvényre viszont az ilyen magas szintű szolgáltatások 
megvalósításához szükség van. A nagyobb sebesség ára a viszonylag kusza felület, de leg- 
alább nem kell újra megvizsgálnunk a bemeneti adatfolyamot, ahhoz, hogy megtudjuk, mi 
szakította meg a beolvasási műveletet; pontosan korlátozhatjuk a beolvasandó karakterek 
számát és így tovább. 


A read(p,n) függvény legfeljebb z karaktert olvas be a D/0/, ..., pÍn-1/ tömbbe. A readO 
nem foglalkozik a bemeneten megjelenő lezáró karakterekkel és az eredménytömb végére 
sem helyez 0 karaktert. Ezért képes tényleg n karaktert beolvasni (és nem csak n-1-0. Te- 
hát a readO függvény egyszerűen karaktereket olvas, és nem próbálja az eredményt C stí- 
lusú karakterlánccá alakítani. 


Az ignoreO függvény ugyanúgy karaktereket olvas, mint a readO), de egyáltalán nem tárol- 
ja azokat. Egy másik hasonlóság a readO függvénnyel, hogy tényleg képes n (és nem n-D 
darab karakter beolvasására. Az ignoreO alapértelmezés szerint egy karaktert olvas be, te- 
hát ha paraméterek nélkül hívjuk meg, akkor jelentése , dobd el a következő karaktert". 
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A getline0 függvényhez hasonlóan itt is megadhatunk egy lezáró karaktert, amit eltávolít 
a bemeneti adatfolyamból, ha beleütközik. Az ignoreO alapértelmezett lezáró karaktere 
a fájlvége jel. Ezeknél a függvényeknél nem világos azonnal, hogy mi állította meg az olva- 
sást, és néha még arra is nehéz emlékezni, melyik olvasási műveletnél mi volt a leállási fel- 
tétel. Azt viszont mindig meg tudjuk kérdezni, hogy elértük-e már a fájlvége jelet (421.3.39. 
Hasonló segítség, hogy a gcountO függvénnyel megállapíthatjuk, hogy a legutóbbi formá- 
zatlan bemeneti eljárás hány karaktert olvasott be az adatfolyamból: 


void read a line(int max) 


( 
Aaa 
if (cin failO) ( // Hopbá: hibás bemeneti formátum 
cin.clearO; // a bemeneti jelzőbitek törlése (§21.3.3) 
cin.ignore(max, ; ); // ugrás a bontosvesszőre 
if (cin) f 
// hoppá: elértük az adatfolyam végét 
j 
else if (cin. gcount0--max) f 
// hoppá: max számú karaktert beolvastunk 
else ( 
// megtaláltuk és eldobtuk a pontosvesszőt 
j 
j 


j 


Sajnos ha a megengedett legtöbb karaktert olvastuk be, nincs módunk annak megállapítá- 
sára, hogy megtaláltuk-e a lezáró karaktert (utolsó beolvasott karakterkénD. 


A paraméter nélküli get0 a ccstdio: fejállományban szereplő getcharO függvény (421.8) 
Ziostream? -beli megfelelője. Egyszerűen beolvas egy karaktert és visszaadja annak szám- 
értékét. Ezzel a megoldással semmit nem kell feltételeznie az éppen használt karaktertípus- 
ról. Ha nincs beolvasható karakter a get) adatfolyamában, akkor a megfelelő fájlvége jelet 
(tehát a traits type::eofO karaktert) adja vissza, majd beállítja az istream objektum eofálla- 
potát (§21.3.39: 


void (unsigned char? p) 


( 
int í; 
while((i - cin.get0) k£ i/-EOF) f 
XDtA  [; 
J/ ... 
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Az EOF az eofO függvény által visszaadott érték a char típus szokásos char. traits osztályá- 
ból. Az EOF értéket az ciostream?: fejállomány határozza meg. Tehát e ciklus helyett nyu- 
godtan írhattuk volna a read(p, MAX INT) utasítást, de tegyük fel, hogy explicit ciklust 
akartunk írni, mert, mondjuk, minden beolvasott karaktert egyesével akartunk látni. A C 
nyelv egyik legnagyobb erősségének tartják azt a lehetőséget, hogy karaktereket olvasha- 
tunk be, és úgy dönthetünk, hogy semmit sem csinálunk velük, ráadásul mindezt gyorsan 
tehetjük. Ez tényleg fontos és alábecsült erősség, így a Ct-t igyekszik ezt megtartani. 


A ccctybe: szabványos fejállomány sok olyan függvényt biztosít, amelynek hasznát vehet- 
jük a bemenet feldolgozásában (420.4.2). Az eatwhiteO0 függvény például, amely az 
üreshely karaktereket törli az adatfolyamból, a következőképpen definiálható: 


istreamk eatwhite(istreamg is) 


í 
char c; 
while Cis.get(c)) f 
if ("isspace(c)) ( // c üreshely karakter? 
is putback(c); // c visszarakása a bemenet átmeneti tárába 
break; 
; 
; 
return is; 
J 


Az is putback(c) függvényhívásra azért van szükség, hogy a c legyen a következő karakter, 
amit az is adatfolyamból beolvasunk (§21.6.4). 


21.3.5. Felhasználói típusok beolvasása 

A felhasználói típusok beolvasását pontosan ugyanúgy lehet megvalósítani, mint kimeneti 
műveleteiket. Az egyetlen különbség, hogy a bemeneti műveletek esetében a második pa- 
raméternek nem-konstans referencia típusúnak kell lennie: 


istiream£k operator::(istreamé s, complexk a) 


/ 
a complex típus lehetséges bemeneti formátumai ("f" lebegőpontos szám) 
f 
(fD 
(SS 
87 
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double re — O, im — 0; 


char c — 0; 
SZG; 
if(c-—- 01 
S$S55TEe55C; 
if(c-—)szzim 55 c; 
if (c 1- )) s.clearGios base::failbit); // állapot beállítása 
) 
else ( 
s. putback(c); 
S 55 TE; 
) 


if (5) a - complex(re, im); 
return s; 


J 


A nagyon kevés hibakezelő utasítás ellenére ez a programrészlet szinte minden hibatípust 
képes kezelni. A lokális c változónak azért adunk kezdőértéket, hogy ha az első 553 műve- 
let sikertelen, nehogy véletlenül pont a ( karakter legyen benne. Az adatfolyam állapotának 
ellenőrzésére a függvény végén azért van szükség, mert az a paraméter értékét csak akkor 
változtathatjuk meg, ha a korábbi műveleteket sikeresen végrehajtottuk. Ha formázási hiba 
történik az adatfolyam állapota failbit lesz. Azért nem badbit, mert maga az adatfolyam nem 
sérült meg. A felhasználó a clearO függvénnyel alapállapotba helyezheti az adatfolyamot és 
továbblépve értelmes adatokat nyerhet onnan. 


Az adatfolyam állapotának beállítására szolgáló függvény neve clearO, mert általában arra 
használjuk, hogy az adatfolyam állapotát goodO értékre állítsuk. Az ios base::clearO 
(421.3.3) paraméterének alapértelmezett értéke ios base::goodbit. 


21.3.6. Kivételek 


Nagyon kényelmetlen minden egyes [I/O művelet után külön ellenőrizni, hogy sikeres volt- 
e, ezért nagyon gyakori hiba, hogy elfelejtünk egy ellenőrzést ott, ahol feltétlenül szükség 
van rá. A kimeneti műveleteket általában nem ellenőrzik, annak ellenére, hogy néha ott is 
előfordulhat hiba. 


Egy adatfolyam állapotának közvetlen megváltoztatására csak a clearO függvényt használ- 
hatjuk. Ezért ha értesülni akarunk az adatfolyam állapotának megváltozásáról, elég nyilván- 
való módszer, hogy a clearO függvényt kivételek kiváltására kérjük. Az ios base osztály 
exceptionsO tagfüggvénye pontosan ezt teszi: 
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template cclass Ch, class Tr - char. traitsZCh: 5 
class basic ios : public ios base f 


public: 
17 ist 
class failure; // kivételosztály (lásd §14.10) 
iostate exceptions const; // kivétel-állapot kiolvasása 
void exceptions(iostate excepb); // kivétel-állapot beállítása 
ÚT sé 

7 


A következő utasítással például elérhetjük, hogy a clearO egy ios base::failure kivételt vált- 
son ki, ha a cout adatfolyam bad, fail vagy eofállapotba kerül, vagyis ha valamelyik műve- 
let nem hibátlanul fut le: 


cout.exceptions(ios base::badbitlios base::failbitlios base::eofbit; 


Ha szükség van rá, a cout vizsgálatával pontosan megállapíthatjuk, milyen probléma tör- 
tént. Ehhez hasonlóan a következő utasítással azokat a ritkának egyáltalán nem nevezhető 
eseteket dolgozhatjuk fel, amikor a beolvasni kívánt adatok formátuma nem megfelelő, és 
ennek következtében a bemeneti művelet nem ad vissza értéket: 


cin.exceptions(ios base::badbit lios base::failbit); 


Ha az exceptionsO függvényt paraméterek nélkül hívjuk meg, akkor azokat az [/O állapot- 
jelzőket adja meg, amelyek kivételt váltanak ki: 


void print exceptions(ios baseg ios) 

f 
ios base::iostate s - ios.exceptionsO; 
if (síios base::badbit) cout cz "bad kivételek"; 
if (síios base::failbit) cout cz "fail kivételek"; 
if (sios base::eofbit) cout c£ "eof kivételek"; 
if (s -—— 0) cout c£ "nincs kivétel"; 


Az [/0 kivételek leggyakoribb felhasználási területe az, hogy a ritkán előforduló (ezért könnyen 
elfelejthető) hibákat kezeljük. Másik fontos feladatuk a ki- és bemenet vezérlése lehet: 
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void readints(vectorkint2g 5) // nem a kedvenc stílusom! 
( 
ios base::iostate old state - cin.exceptionsO; // menti a kivétel-állapotot 
cin.exceptions(ios base::eofbiD; // eof kivételt vált ki 
for G) 
try ( 
int í; 
CÍN5Dí; 


s.push back(i; 
j 
catch(ios base::failure) f 

// rendben: elértük a fájl végét 
j 


cin.exceptions(old state); // kivétel-állapot visszaállítása 


J 


A kivételek ilyen formában való felhasználásakor felmerül a kérdés, nevezhetjük-e az adott 
helyzetet hibának vagy tényleg kivételes helyzetnek. Általában mindkét kérdésre inkább 
a nem választ adjuk, ezért úgy gondolom, célszerűbb az adatfolyam állapotát közvetlenül 
vizsgálni. Amit egy függvény belsejében, lokális vezérlési szerkezetekkel kezelhetünk, azt 


a kivételek sem kezelik jobban. 


21.3.7. Adatfolyamok összekötése 


A basic ios osztály tie0 függvénye arra használható, hogy kapcsolatot létesítsünk egy 


istream és egy ostream között: 


template cclass Ch, class Tr - char. traitsZCh: 5 
class std::basic ios : public ios base ( 


Me 


basic ostreamzZCh,Tr2? tieO) const; // mutató összekötött adatfolyamokra 
basic ostream£Ch,Tr2" tie(basic ostreamzCh,Tr2" s); // "this hozzákötése s-hez 


1 zés 


Ji 
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Vegyük például az alábbi programrészletet: 


string get passwdO 


string s; 

cout cz "Jelszó: "; 
cin 535 s; 

VESS 


Hogyan bizonyosodhatnánk meg arról, hogy a Jelszó: szöveg megjelent-e a képernyőn, mi- 
előtt a bemeneti műveletet végrehajtjuk? A cout adatfolyamra küldött kimenet átmeneti tár- 
ba kerül, így ha a cin és a cout független egymástól, a Jelszó esetleg mindaddig nem jele- 
nik meg a képernyőn, amíg a kimeneti tár meg nem telik. A megoldást az jelenti, hogy 
a cout adatfolyamot hozzákötjük a cin adatfolyamhoz a cin.tie(k cout) utasítással. 


Ha egy ostream objektumot összekötünk egy istream objektummal, az ostream mindig ki- 
ürül, amikor egy bemeneti művelet alulcsordulást okoz az istream adatfolyamban, azaz 
amikor egy bemeneti feladat végrehajtásához új karakterekre van szükség a kijelölt beme- 
neti eszközről. Tehát ilyenkor a 


cout cz "Jelszó: "; 
cin 535 s; 


utasítássorozat egyenértékű az alábbival: 


cout 22 "Jelszó: "; 
cout flushO; 
cin 35 s; 


Adott időben minden adatfolyamhoz legfeljebb egy oszream objektum köthető. Az s.tie(O) 
utasítással leválaszthatjuk az s objektumhoz kötött adatfolyamot (ha volt ilyen). A többi 
olyan adatfolyam-függvényhez hasonlóan, melyek értéket állítanak be, a tie(s5) is a korábbi 
értéket adja vissza, tehát a legutóbb ide kötött adatfolyamot, vagy ha ilyen nincs, akkor a 0 
értéket. Ha a tie0 függvényt paraméterek nélkül hívjuk meg, akkor egyszerűen visszakap- 
juk az aktuális értéket, annak megváltoztatása nélkül. 


A szabványos adatfolyamok esetében a cout hozzá van kötve a cin bemenethez, a wcout 
pedig a wcin adatfolyamhoz. A cerr adatfolyamot felesleges lenne bármihez is hozzákötni, 
mivel ehhez nincs átmeneti tár, a clog pedig nem vár felhasználói közreműködést. 
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21.3.8. Őrszemek 


Amikor a CZ és a 5: operátort a complex típusra használtuk, egyáltalán nem foglalkoztunk 
az összekötött adatfolyamok (421.3.7) kérdésével, vagy azzal, hogy az adatfolyam állapotá- 
nak megváltozása kivételeket okoz-e (§21.3.60). Egyszerűen azt feltételeztük (és nem ok nél- 
kül, hogy a könyvtár által kínált függvények figyelnek helyettünk ezekre a problémákra. 
De hogyan képesek erre? Néhány tucat ilyen függvénnyel kell megbirkóznunk, így ha olyan 
bonyolult eljárásokat kellene készítenünk, amely az összekötött adatfolyamokkal, a helyi 
sajátosságokkal (locale, §21.7, §D), a kivételekkel, és egyebekkel is foglalkoznak, akkor 
igen kusza kódot kapnánk. 


A megoldást a sentry ( őrszem") osztály bevezetése jelenti, amely a közös kódrészleteket 
tartalmazza. Azok a részek, melyeknek elsőként kell lefutniuk (a , prefix kód", például egy 
lekötött adatfolyam kiürítése), a sentry konstruktorában kaptak helyet. Az utolsóként futó 
sorokat (a , suffix kódokat", például az állapotváltozások miatt elvárt kivételek kiváltásáp 
a sentry destruktora határozza meg: 


template cclass Ch, class Tr - char. traitsZCh: 5 

class basic ostream : virtual public basic ioszCh, Tr: ( 
Sa 
class sentry; 


Mész 


2; 
template Sclass Ch, class Tr - char. traiszCh: 2 
class basic ostreamzCh,Tr2::sentry ( 

bublic: 

explicit sentry(basic ostreamzCh Ir: 5); 
-sentryO; 

operator boolO; 


Ia 


J; 


Tehát egy általános kódot írtunk, melynek segítségével az egyes függvények a következő 
formába írhatók: 


template cclass Ch, class Tr - char. traitsZCh: 5 
basic ostreamzZCh,Tr-k basic ostreamzCh, Tr5::operatorzc(int i) 
( 
sentry sCthis); 
if (15) ( // ellenőrzés, minden rendben van-e a kiírás megkezdéséhez 
setstate(failbit); 
return "this; 
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// az int kiírása 
return "this; 


J 


A konstruktorok és a destruktorok ilyen jellegű felhasználása általános az előtag (prefix) és utó- 
tag (suffix) kódrészletek beillesztéséhez, és nagyon sok helyzetben alkalmazható módszer. 


Természetesen a basic istream hasonló sentry tagosztállyal rendelkezik. 


21.4. Formázás 


A §21.2. pontban bemutatott példák mind abba a kategóriába tartoztak, amit általánosan 
Jformázatlan kimenetnek Cunformatted outpuD) nevezünk. Ez azt jelenti, hogy az objektu- 
mot úgy alakítottuk karaktersorozattá, hogy csak alapértelmezett szabályokat használtunk. 
A programozóknak gyakran ennél részletesebb vezérlési lehetőségekre van szükségük. Né- 
ha például meg kell határoznunk, hogy a kimenet mekkora területet használjon, vagy hogy 
a számok milyen formában jelenjenek meg. Az ehhez hasonló tényezők vezérlésére a be- 
menet esetében is szükség lehet. 


A ki- és bemenet formázását vezérlő eszközök a basic ios osztályban, illetve annak 
ios base bázisosztályában kaptak helyet. A basic ios például információkat tartalmaz 
a számrendszerről (nyolcas, tízes vagy tizenhatos), amit egész számok kiírásakor és beolva- 
sásakor használ a rendszer, vagy a lebegőpontos számok pontosságáról és így tovább. 
Az ezen adatfolyam-szintű (minden adatfolyamra külön beállítható) változók lekérdezésé- 
re és beállítására szolgáló függvények szintén ebben az osztályban kaptak helyet. 


A basic ios bázisosztálya a basic istream és a basic ostream osztálynak, így a formázás ve- 
zérlése minden adatfolyamra külön adható meg. 
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21.4.1. Formázási állapot 


A ki- és bemenet formázását néhány jelzőbit és néhány egész érték vezérli, melyek az adat- 
folyamok ios base bázisosztályában szerepelnek: 


class ios base f( 
bublic: 
VAS 


// formázásjelzők neveit: 


typedefmegvalósítás függől fmiflags; 
static const fmtflags 


skipuws, // üreshelyek átlépése a bemeneten 

left, // mezőigazítás: feltöltés az érték után 

right, // feltöltés az érték előtt 

internal, // feltöltés előjel és érték között 

boolalpha, // a true és false szimbolikus megjelenítése 

dec, // számrendszer alapja egészeknél: 10 (decimális) 


hex, // 16 (hexadecimális) 
ocI, // 8 (oktális) 
scientific, // lebegőpontos jelölés: d.ddddddEdd 
fixed, // dddd.dd 
showbase, // kiíráskor oktálisak elé O, hexadecimálisok elé 0x előtag 
showpoint, // a záró nullák kiírása 
showpos, // a! a pozitív egészek elé 
uppercase, // E, "(XI alkalmazása Ce, :x! helyett) 
adjustfield, // mezőigazítással kapcsolatos jelző (§21.4.5) 
basefield, // egész számrendszer alapjával kapcsolatos jelző (§21.4.2) 
floatfield; // lebegőpontos kimenettel kapcsolatos jelző (§21.4.3) 
Jfimtflags unitbuj; // minden kimenet után az átmeneti tár ürítése 
Jfimiflags flagsO const; // jelzőbitek kiolvasása 
Jfimtflags flags(fmtflags P); // jelzőbitek beállítása 


Jfimtflags setffmtflags f) f return flags(flagsO IP; ? // jelzőbit hozzáadása 
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// a jelzőbitek törlése és beállítása a maszkban 
Jmtflags setf(fmtjflags f, fmtflags mask) ( return flags((flagsOk-masRk) I(jk mask); ; 
void unsetf(jmtflags mask) ( flags(flagsOk-mask); ? // jelzőbitek törlése 


VÁLSET 
1; 


Az egyes jelzőbitek (flag) értéke az adott nyelvi változattól függ, így mindig a szimbolikus 
neveket használjuk a konkrét számértékek helyett, még akkor is, ha az általunk használt ér- 
tékek véletlenül éppen megfelelően működnek. 


Egy felületet jelzők sorozatával, illetve azokat beállító és lekérdező függvényekkel megha- 
tározni időtakarékos, de kicsit régimódi módszer. Legfőbb erénye, hogy a felhasználó a le- 
hetőségeket összeépítheti: 


const ios base::fmtflags my opt - ios base::leftlios base::octlios base::fixed; 


Ez lehetővé teszi, hogy egy függvénynek beállításokat adjunk át, és akkor kapcsoljuk be 
azokat, amikor szükség van rájuk: 


void your. function(ios base::fmtflags opD) 

( 
ios base::fmiflags old. options - cout flags(opD); // régi beállítások mentése, újak beállítása 
MT ád 
cout flags(old options); // visszaállítás 


j 


void my functionO 
( 


your. function(my opW; 
VÜAEES 
J 


A flagsO függvény az eddig érvényben levő beállításokat adja vissza. 


Ha képesek vagyunk az összes tulajdonság együttes írására és olvasására, egyesével is be- 
állíthatjuk azokat: 


myostream jflags(myostream flagsO lios base::showpos); 


Ezen utasítás hatására a myostream adatfolyam minden pozitív szám előtt egy - jelet fog 
megjeleníteni; más beállítások nem változnak meg. Először beolvassuk a régi beállításokat, 
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majd beállítjuk a showpos tulajdonságot úgy, hogy az eredeti számhoz a bitenkénti vagy 
művelettel hozzákapcsoljuk ezt az értéket. A setf0 függvény pontosan ugyanezt teszi, tehát 
a fenti példával teljesen egyenértékű az alábbi sor: 


myostream.setf(ios base::showpos); 
Egy jelző mindaddig megtartja értékét, amíg azt meg nem változtatjuk. 


A ki- és bemeneti tulajdonságok vezérlése a jelzőbitek közvetlen beállításával igen nyers 
megoldás és könnyen hibákhoz vezethet. Az egyszerűbb esetekben a módosítók 
(manipulator) (421.4.6) tisztább felületet adnak. A jelzőbitek használata egy adatfolyam ál- 
lapotának vezérlésére a megvalósítási módszerek tanulmányozásához megfelel, a felületter- 
vezéshez már kevésbé. 


21.4.1.1. Formázási állapot lemásolása 
A copyfmtO függvény segítségével egy adatfolyam teljes formázási állapotát lemásolhatjuk: 


template cclass Ch, class Tr - char. traitsZCh: 5 
class basic ios : public ios base f 
bublic: 

M8a 

basic iosdt copyfmt(const basic iosk f); 

VES 


J; 


Az adatfolyam átmeneti tárán (421.6) és annak állapotán kívül a copyfmtO minden állapot- 
tulajdonságot átmásol, tehát a kivételkezelési módot (421.3.6) és a felhasználó által meg- 
adott további beállításokat is (421.7.1). 


21.4.2. Egész kimenet 


A ,bitenkénti vagy" használata egy új beállítás megadásához a /lagsO és setfO függvények 
segítségével csak akkor használható, ha az adott tulajdonságot egy bit határozza meg. Nem 
ez a helyzet azonban egy olyan jellemzőnél, mint például az egészek kiírásához használt 
számrendszer vagy a lebegőpontos számok kimeneti formátuma. Az ilyen tulajdonságok 
esetében az érték, amely egy adott stílust ábrázol, nem fogalmazható meg egyetlen bittel 


vagy akár egymástól független bitek sorozatával. 
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Az ciostream? fejállományban alkalmazott megoldás az, hogy a setfŐ függvény olyan vál- 
tozatát határozza meg, amelynek egy második, , álparamétert" is meg kell adnunk. Ez a pa- 
raméter határozza meg, milyen tulajdonságot akarunk beállítani az új értékkel: 


cout.setf(ios base::oct,ios base::basefield); // oktális 
cout.setf(ios base::dec,ios base::basefield); // decimális 
cout.setf(rios base::hex,ios base::basefield); // hexadecimális 


Ezek az utasítások az egészek számrendszer-alapját állítják be, anélkül, hogy az adatfolyam 
állapotának bármely más részét megváltoztatnák. Az alapszám mindaddig változatlan ma- 
rad, amíg meg nem változtatjuk. Például az alábbi utasítássorozat eredménye 71234 1234 
2322 2322 4d2 4d2. 


cout c£ 1234 cc !! cc 1234 cc! t // alapértelmezett: decimális 


cout.setf(ios base::oct,ios base::basefield); // oktális 
cout cz 1234 cc ! ! cz 1234 cc!) 


cout.setf(rios base::hex,ios base::basefield); // hexadecimális 
cout cz 1234 cc ! ! cz 1234 cc!) 


Ha az eredményről meg kell tudnunk állapítani, hogy melyik szám milyen számrendszerben 
értendő, a snhowbase beállítást használhatjuk. Tehát ha az előbbi utasítások elé beszúrjuk a 


cout.setf(ios base::showbase); 


utasítást, akkor az 1234 1234 02322 02322 0x4d2 0x4ád2 számsorozatot kapjuk. A szabvá- 
nyos módosítók (manipulator) (421.4.6.2) elegánsabb megoldást kínálnak az egész számok 
kiírásához használt számrendszer beállítására. 


21.4.3. Lebegőpontos szám kimenet 


A lebegőpontos számok kimenetét két tényező befolyásolja: a formátum (format) és a bpon- 
tosság (precision). 

6 Az általános (general) formátum lehetővé teszi a megvalósítás számára, hogy olyan 
számformátumot használjon, amely a rendelkezésre álló területen a lehető legjob- 
ban ábrázolja a lebegőpontos értéket. A pontosság a megjelenő számjegyek maxi- 
mális számát határozza meg. Ez a jellemző a printfO függvény 90g beállításának 
felel meg (421.8). 
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6 A tudományos (scientific) formátumban egy számjegy szerepel a tizedespont előtt, 
és egy kitevő (exponens) határozza meg a szám nagyságrendjét. A pontosság ez 
esetben a tizedespont után álló számjegyek maximális számát jelenti. Ezt az esetet 
a printf függvény 96e beállítása valósítja meg. 

6 A /ixpontos (fixed) formátum a számot egészrész, tizedespont, törtrész formában je- 
leníti meg. A pontosság most is a tizedespont után álló számjegyek számának maxi- 
mumát adja meg. A printfO függvény 9efbeállítása viselkedik így. 


A lebegőpontos számok kimeneti formátumát az állapotmódosító függvények (state 
manipulator function) segítségével szabályozhatjuk. Ezek felhasználásával a lebegőpontos 
értékek megjelenítését úgy állíthatjuk be, hogy az adatfolyam állapotának más részeit nem 
befolyásoljuk: 


cout 2 "Alapértelmezett:M" SZ 1234.56789 cz M; 


cout.setf(ios base::scientific,ios base::floatfield); // tudományos formátum használata 
cout cz "Tudományos:M" ££ 1234.567989 cz MM; 


cout.setf(ios base::fixed,ios base::floatfield); /[/ fixpontos formátum használata 
cout c£ "Fixpontos:M" c£ 1234.56789 cz Mm; 


cout.setf(O,ios base::floatfield); // alapértelmezés visszaállítása 
// (általános formátum) 
cout cz "Alapértelmezett:M" cz 1234.56789 cz MM; 


Az eredmény a következő lesz: 


default: 1234.57 
scientific: 1.234568e403 
fixed: 1234.567890 
default: 1234.57 


A pontosság alapértelmezett értéke minden formátum esetében 6, amit az ios base osztály 
külön tagfüggvényével módosíthatunk: 


class ios base f( 
bublic: 
VZEBE 
streamsize precisionO const; // pontosság lekérdezése 
streamsize precision(streamsize n); // pontosság beállítása (és a régi pontosság lekérdezése) 


Man 


J; 
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A precisionO függvény meghívásával minden lebegőpontos [/O művelet pontosságát meg- 
változtatjuk az adatftolyamban a függvény következő meghívásáig. Ezért a 


cout precision(8); 
cout ££ 1234.56789 ac ! ! cc 1234.56789 ac ! ! cz 123456 cc Mi; 


cout.precision(4); 
cout 22 1234.56789 cc ! ! cc 1234.56789 cc ! ! cc 123456 cc Mt 


utasítássorozat eredménye a következő lesz: 


1234.5679 1234.5679 123456 
1235 1235 123456 


A példában két dolgot figyelhetünk meg: az egyik, hogy a lebegőpontos értékek kerekítve 
jelennek meg, nem egyszerűen levágva, a másik, hogy a precisionO az egész értékek meg- 
jelenítésére nincs hatással. 


Az uppercase jelzőbit (§21.4.1) azt határozza meg, hogy a tudományos formátumban e vagy 
E betű jelölje a kitevőt. 


A módosítók (manipulator) elegánsabb megoldást kínálnak a lebegőpontos számok kime- 
neti formátumának beállítására (421.4.6.2). 


21.4.4. Kimeneti mezők 


Gyakran arra van szükségünk, hogy egy kimeneti sor adott területét töltsük fel szöveggel. 
Ilyenkor pontosan n karaktert akarunk használni, kevesebbet semmiképp (többet pedig 
csak akkor, ha a szöveg nem fér el a meghatározott területen). Ehhez meg kell adnunk a te- 
rület szélességét és a kitöltő karaktert: 


class ios base ( 


public: 
Ül ses 
streamsize widthO const; // mezőszélesség lekérdezése 
streamsize width(streamsize wide); // mezőszélesség beállítása 
Mese 

s 


template cclass Ch, class Tr - char. traitsZCh: 5 
class basic ios : public ios base f 
bublic: 

ÚT só 
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Ch fill0 const; // kitöltő karakter lekérdezése 
Ch fillC(ch ch); // kitöltő karakter beállítása 
HAKK 


J; 


A widthO függvény a kimenő karakterek legkisebb számát határozza meg a standard 
könyvtár következő olyan cc műveletében, amellyel számértéket, logikai értéket, C stílusú 
karakterláncot, karaktert, mutatót (§21.2.1), string objektumot (420.3.15) vagy bitfield válto- 
zót (417.5.3.3) írunk ki: 


cout.width(4); 
cout cZ£ 12; 


Ez az utasítás a 12 számot két szóköz karakter után írja ki. 
A kitöltő karaktert a fill0 függvény segítségével adhatjuk meg: 
cout. width(4); 


cout fillC s); 
cout cz "ab"; 


Az eredmény ézab lesz. 


Az alapértelmezett kitöltő karakter a szóköz, az alapértelmezett pontosság pedig 0, ami 
annyi karaktert jelent, amennyire szükség van. A kimeneti mező méretét tehát a következő 
utasítással állíthatjuk vissza alapértelmezett értékére: 


cout.width(09; // "annyi karakter, amennyi csak kell" 


A width(n) utasítással a kiírható karakterek legkisebb számát n-re állítjuk. Ha ennél több 
karaktert adunk meg, akkor azok mind megjelennek: 


cout. width(4); 
cout 2 "abcdef ; 


Az eredmény abcdef lesz, nem pedig csak abcd. Ez azért van így, mert általában jobb 
a megfelelő értéket csúnya formában megkapni, mint a rossz értéket szépen igazítva (ásd 
még §21.10[21D. 
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A width(n) függvényhívás csak a közvetlenül utána következő cc kimeneti műveletre 
vonatkozik: 


cout.width(4); 
cout fillC); 
cout ££ 12 c£ I! 22 13; 


Az eredmény csak Á472:13 lesz és nem Afl2éét:4413, ami akkor jelenne meg, ha 
a width(4) minden későbbi műveletre vonatkozna. Ha a widthO függvényt több, egymás 
utáni kimeneti műveletre is alkalmazni szeretnénk, kénytelenek leszünk minden egyes ér- 
tékhez külön-külön megadni. 


A szabványos módosítók (modifier) (421.4.6.2) elegánsabb megoldást kínálnak a kimeneti 
mezők méretének szabályozására is. 
21.4.5. Mezők igazítása 


A karakterek mezőn belüli igazítását (adjustmenD) a setf0 függvény meghívásával állíthat- 
juk be: 


cout.setf(ios base::left,ios base::adjustfield); // bal 
cout.setf(ios base::right,ios base::adjustfield); // jobb 
cout.setf(ios base::internal,ios base::adjustfield); // belső 


Ezek az utasítások az ios base::widthO függvénnyel meghatározott kimeneti mezőn belül 
adják meg az igazítást, az adatfolyam egyéb beállításaira nincsenek hatással. 


Az igazítást a következőképpen használhatjuk. 
cout fillCs); 


cout c£ (; 
cout.width(4); 
cout cz -12 cc") (; 


cout.width(4); 
cout.setf(ios base::left,ios base::adjustfield); 
cout cz -12 cc") (; 


cout.width(4); 
cout.setf(ios base::internal,ios base::adjustfield); 
cout cz -12 cc"); 
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Az eredmény: (r-12), (-124), (-4129. Az internal beállítás a kitöltő karaktereket az előjel és az 
érték közé helyezi. A példából láthatjuk, hogy az alapértelmezett beállítás a jobbra igazítás. 


21.4.6. Módosítók 


A standard könyvtár szeretné megkímélni a programozót attól, hogy az adatfolyamok álla- 
potát jelzőbiteken keresztül állítsa be, ezért külön függvényeket kínál ezen feladat megol- 
dásához. Az alapötlet az, hogy a kiírt vagy beolvasott objektumok között adjuk meg azokat 
a műveleteket is, melyek az adatfolyam állapotát megváltoztatják. Az alábbi utasítással pél- 
dául a kimenet átmeneti tárának azonnali kiürítésére szólíthatjuk fel az adatfolyamot: 


cout ££ x cz flush cz y cz flush; 


A megfelelő helyeken a couz.flushO függvény fut le. Ezt az ötletet úgy valósíthatjuk meg, 
hogy egy olyan cc változatot készítünk, amely egy függvényre hivatkozó mutatót vár para- 
méterként és törzsében lefuttatja a hivatkozott függvényt: 


template cclass Ch, class Tr - char. traitsZCh: 5 
class basic ostream : virtual public basic ioszCh, Tr: ( 
bublic: 

sás 


basic ostreamk operatorzs(basic ostreamk CfP(basic ostream£)) ( return fCthis); ) 
basic ostreamk operatorzz(ios basek ("f)(ios baseg )); 
basic ostreamk operatorss(basic ioszCh,Tr-k CfP(basic ioszCh, Ir2£); 


Ms 


Ahhoz, hogy ez a megoldás működjön, a (mutatóként átadott) függvénynek nem szabad 
tagfüggvénynek lennie (legfeljebb statikus tagfüggvénynek), és a megfelelő típussal kell 
rendelkeznie. Ezért a /lushO függvényt például a következőképpen kell meghatároznunk: 


template cclass Ch, class Tr - char. traiszCh: 2 
basic ostreamzCh,Tr-k flush(basic ostreamzZCh Tr:£ s) 
t 


return s. flushO;  /7 az ostream osztály flushO tagfüggvényének meghívása 


J/ 


Ezen deklarációk után a 


cout cz flush; 
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utasítás egyenértékű lesz a 


cout.operatorsa(flush); 


utasítással, ami pedig meghívja a 
Jflush(coun; 


függvényt, így végül a 


cout flushO; 
kerül végrehajtásra. 


A teljes eljárás fordítási időben történik, így lehetővé teszi, hogy a basic ostream::flushO 
függvényt coutcsflush formában hívjuk meg. Nagyon sok olyan művelet van, amelyet köz- 
vetlenül egy ki- vagy bemeneti művelet előtt vagy után akarunk végrehajtani: 


cout 22 Xx; 

cout flushO; 

cout £Z y; 

unset(ios base::skipws); // ne ugorjuk át az üreshelyeket 
cin 525 Xx; 


Ha ezeket a műveleteket külön utasításokként kell megfogalmaznunk, a műveletek közöt- 
ti kapcsolatok kevésbé fognak látszódni, márpedig az ilyen logikai kapcsolatok elvesztése 
erősen rontja a program olvashatóságát. A módosítók (manipulator) lehetővé teszik, hogy 
az olyan műveleteket, mint a /lushO és a noskipwsO, közvetlenül a ki- vagy bemeneti mű- 
veletek listájában helyezzük el: 


cout cz x c£ flush cz y c flush; 
cin 55 noskipws 22 Xx; 


Megjegyzendő, hogy a módosítók az szd névtérhez tartoznak, ezért minősítenünk kell azo- 
kat, amennyiben az szd nem része az adott hatókörnek: 


std::cout 2 endi; // hiba: endi nincs a hatókörben 
std::cout 2 std::endl; // rendben 
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Természetesen a basic istream a módosítók számára is ugyanúgy biztosítja a 22 operátoro- 
kat, mint a basic ostreami: 


template cclass Ch, class Tr - char. traitsZCh: 5 
class basic istream : virtual public basic ioszCh,Tr: ( 
bublic: 
S /gRE 
basic istream£k operator:P(basic istream£ ("pfó(basic istream£ )); 
basic istream£k operator:r(basic ioszCh Tr-k Cpf(basic ioszCh,Ir2£)); 
basic istream£k operator::(ios base ("pfd(ios baseg )); 


ATS 


J; 


21.4.6.1. Módosítók, melyek paramétereket várnak 


Nagyon hasznosak lennének az olyan módosítók is, melyeknek paramétereket is át tudunk 
adni. Például jó lenne, ha leírhatnánk az alábbi sort, és vele az angle lebegőpontos változó 
megjelenítését 4 jegy pontosságúra állíthatnánk: 


cout 22 setprecision(4) cz angle; 


Ennek eléréséhez a setprecision-nek egy objektumot kell visszaadnia, amelynek a 4 kezdő- 
értéket adjuk, és amely meghívja a cout::setprecision(4) függvényt. Az ilyen módosítók függ- 
vényobjektumok, amelyeket a 0 helyett a cc operátor hív meg. A függvényobjektum pon- 
tos típusa az adott megvalósítástól függ; egy lehetséges definíciója például a következő: 


struct smanip f 
ios basoek CfCios basek , int; // meghívandó függvény 


int í; 


smanip(ios base CjpcGios basek,int), int ii) : ff), iii) 1 ?) 
2. 


Jo 


templatexclass Ch, class Tr: 
ostreamzCh, Tr:k operatorzs(ostreamzCh, Tr:d os, const smanipk m) 


( 


return m f(ossm.i); 
2 


s 
Az smanip konstruktor paramétereit az /-ben és az í-ben tárolja, majd az operatorsz egy fi) 
függvényhívást hajt végre. Ennek felhasználásával a fenti setprecisionÖ módosító a követ- 
kezőképpen definiálható: 
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ios basek set precision(ios baseg s, int n) // segéd 
( 
return s.precision(n); // a tagfüggvény hívása 
J 
inline smanip setprecision(int n) 
( 
return smanip(set precision n); // függvényobjektum létrehozása 
J 


Így már leírhatjuk az utasítást: 


cout 22 setprecision(4) cz angle ; 


A programozók saját módosítókat is megadhatnak az smanip stílusában, ha más lehetősé- 
gekre is szükségük van (421.10[22D. Ehhez nem kell megváltoztatniuk a standard könyvtár 
osztályait és sablonjait (például basic istream, basic ostream, basic ios vagy ios base). 


21.4.6.2. Szabványos ki- és bemeneti módosítók 


A standard könyvtárban sok módosító (manipulator) szerepel a különböző formázási állapo- 
tok kezeléséhez. A szabványos módosítók az std névtérben találhatók. Az ios base osztályhoz 
kapcsolódó módosítók az Cios2 fejállományon keresztül érhetők el, míg az istream vagy az 
ostream felhasználásával működő módosítók az Cistream: és az Costream: Glletve néha az 
Ziostream?) fejállományból. A többi szabványos módosítót az Ciomanip: fejállomány adja 
meg. 


ios basek boolalphac(ios baseg); // true és false szimbolikus jelzése (bemenet és 
// kimenet) 
ios basek noboolalpha(ios baseg s); // s.unsetf(ios base::boolalpha) 


ios basek showbase(ios baseg ); // kimenetnél oktálishoz O, hexadecimálishoz Ox 
// előtag 
ios basek noshowbase(ios baseg s); // s.unsetf(ios base::showbase) 


ios basek showpoint(ios base ); 
ios basek noshowpoint(ios baseg s); // s.unsetf(ios base::showpoinb) 


ios basek showpos(ios based ); 
ios basek noshowpos(ios basek s); — // s.unsetf(ios base::showpos) 


ios baseg skipws(ios baseg); // üreshelyek átugrása 
ios base noskipws(ios based 5); // s.unsetf(ios base::skipws) 
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ios basog uppercase(ios based ); // X és E (x és e helyet) 
ios basoeg nouppercase(ios base);  //.x és e (X és E helyet) 


ios basek internal(ios baseg ); // igazítás (§21.4.5) 

ios baseg left(ios baseg ); // feltöltés érték után 

ios basek right(ios basek); // feltöltés érték előtt 

ios basegk dec(ios basek ); // egész számrendszer alapja: 10 (§21.4.2) 
ios basok hex(ios base£ ); // egész számrendszer alapja: 16 

ios baseg oct(ios based); // egész számrendszer alapja: 8 

ios baseg fixed(ios base); // lebegőpontos, fixpontos: dddd.dd (§21.4.3) 
ios basek scientific(ios based ); // tudományos formátum: d.ddddEdd 


template cclass Ch, class Tr: 
basic ostreamcCh,Tr:k endkbasic ostreamzCh,Tr:£ ); SM kiírása és az 
// adatfolyam ürítése 
template cclass Ch, class Tr: 
basic ostream£Ch,Trc-k ends(basic ostreamcCh,Tr2£); // NO" kiírása és az 
// adatfolyam ürítése 
template cclass Ch, class Tr: 
basic ostreamZCh,Trr:é flush(basic ostreamzCh,Ir2£ 9; // az adatfolyam ürítése 


template cclass Ch, class Tr: 


basic istreamzCh Tr-2k ws(basic istreamzCh,Tr2£); // üreshely "lenyelése" 

smanip resetiosjflags(ios base::fmtflags P; // jelzőbitek törlése (§21.4) 

smanip setiosflags(ios base::fmtflags P; // jelzőbitek beállítása (§21.4) 

smanip setbaseCGint b); // egészek kiírása b alapú számrend 
// szerben (§21.4.2) 

smanip setfillrint c); // legyen c a kitöltő karakter (§21.4.4) 

smanip setprecision(int n); // n számjegy (§21.4.3, §21.4.6) 

smanip setu(int n); // a következő mezőszélesség n karakter 
// (§21.4.4) 


Például a 
cout c 1234 cc !! cc hex cz 1234 cc !! cc oct cz 1234 cc endl; 
utasítás eredménye 1234, 4d2, 2322, míg a 


cout 2 (" cz setu(4) cz setfill( 6) cz 12 cz ") (" cz 12 cc IN; 


eredménye (4412) (127. 
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Figyeljünk rá, hogy ha olyan módosítókat használunk, melyek nem vesznek át paramétere- 
ket, akkor nem szabad kitennünk a zárójeleket. A paramétereket is fogadó módosítók hasz- 
nálatához az Ciomanip? fejállományt be kell építenünk ($include): 


finclude Ciostream: 
using namespace stid; 


int mainŐ 


( 
cout 22 setprecision(4)  // hiba: setprecision nem meghatározott (£iomanip: kimaradt) 
za scientificO // hiba: ostreamszostreamkg ("hamis" zárójelek) 
2z 3.141421 cc endi; 
J 


21.4.6.3. Felhasználói módosítók 


A szabványos módosítók stílusában a programozó is készíthet új módosítókat. Az alábbiak- 
ban egy olyan eszközt mutatunk be, melynek a lebegőpontos számok formázásakor vehet- 
jük hasznát. 


A pontosság minden további kimeneti műveletre vonatkozik, míg a szélesség-beállítás csak 
a következő numerikus kimeneti utasításra. Célunk most az lesz, hogy egy lebegőpontos 
számot az általunk megkívánt formában jelenítsünk meg, anélkül, hogy a későbbi kimene- 
ti műveletek formázására hatással lennénk. Az alapötlet az, hogy egy olyan osztályt készí- 
tünk, amely formátumokat ábrázol, és egy olyat, amely a formázáson kívül a formázni kí- 
vánt értéket is tárolja. Ennek felhasználásával készíthetünk egy olyan c£ operátort, amely 
a kimeneti adatfolyamon az adott formában jeleníti meg az értéket: 


Form gen4(4); // általános formátum, pontosság 4 
void (double d) 
( 
Form sci8 - gen4; 
sci8.scientificO.precision(8); // tudományos formátum, pontosság 8 


cout cz d c£ !! cz gen4(d) ca ! ! cz scig(d) cz ! "cd cz Mt 


J 


Az (1234.56 789) függvényhívás eredménye a következő lesz: 


1234.57 1235 1.23456789e403 1234.57 


Figyeljük meg, hogy egy Form használata nem befolyásolja az adatfolyam állapotát, hiszen 
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a d utolsó kiíratásakor ugyanazt a formát kapjuk, mint az elsőben. 


Íme, egy leegyszerűsített változat: 


class Bound form; // forma és érték 


class Form f 
friend ostream£ operators(ostreamkg, const Bound formát ); 


int prc; // pontosság 

int wdt; // szélesség, O jelentése: a szükséges szélesség 

int fmt; // általános, tudományos, vagy fix (§21.4.3) 

17 a 

bublic: 

explicit Form(int p — 6) : prc(p) // alapértelmezett pontosság 6 

( 
Jfmt - 0; // általános formátum (§21.4.3) 
wdt - 0; // szükséges szélesség 

j 

Bound form operatorO(double d) const; // Bound form objektum létrehozása "this 


// és d alapján 


Formég scientificO f fmt - ios base::scientific; return "this; ) 
Formá£ fixedO ( fmt -— ios base::fixed; return "this; ) 
Formá generalO ( fmt - O; return "this; ) 


Form£ uppercaseO; 
Formá lowercaseO; 
Formé precision(int p) ( prc — p; return "this; ) 


Formg width(int w) ( wdt - w; return "this; ) // minden típusra 
Formág fill(char); 

Formég plus(bool b - true); // explicit pozitív előjel 
Formá trailing zeros(bool b - true); // záró nullák kiírása 
I zta 


Az ötlet az, hogy a Form minden olyan információt tárol, ami egy adatelem formázásához 
szükséges. Az alapértelmezett értékeket úgy választottuk meg, hogy azok a legtöbb esetben 
megfelelők legyenek; az egyes formázási beállításokat a tagfüggvények segítségével külön- 
külön adhatjuk meg. A kiírandó értékhez a meghatározott formázást a ( ) operátor segítsé- 
gével kötjük hozzá. A Bound form objektum ezek után a megfelelő cc operátor segítségé- 
vel tetszőleges kimeneti adatfolyamon megjeleníthető: 
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struct Bound form f 
const Formá f; 
double val; 


Bound form(const Formá ff, double v) : KI, vakw) ( ; 
Hz 


Bound form Form::operatorO(double d) f return Bound form( "this, 49; ) 


ostreamk operatorsá(ostreamdkg os, const Bound formát bf) 


( 
ostringstream s; // karakterlánc-folyamok leírása: 621.5.3 
s.precision(bf.f.Pro); 
s.setf(bff.fmt,ios base::floatfield); 
s cz bfival; // s összeállítása 
return os ££ s.strO; // s kiírása os-re 
J 


A cc operátor egy kevésbé egyszerű változatának elkészítését feladatnak hagyjuk 


(§21.10I21D. A Form és a Bound form osztályt könnyen kibővíthetjük, hogy egészek, ka- 
rakterláncok stb. formázására is használható legyen (lásd §21.10[20D. 


Megfigyelhetjük, hogy ezen deklarációk a cc és a ( ) párosításával egy hármas operátort 
hoznak létre. A coutccsciá(d) utasítással egyetlen függvényben kapcsolunk össze egy 
ostream objektumot, egy formátumot és egy értéket, mielőtt a tényleges műveletet végre- 
hajtanánk. 


21.5. Fájl- és karakterlánc-folyamok 


Amikor egy Ct-4 programot elindítunk, a cout, a cerr, a clog, és a cin, illetve 
széleskarakteres megfelelőik (421.2.1) azonnal elérhetők. Ezeket az adatfolyamokat a rend- 
szer automatikusan hozza létre és köti hozzá a megfelelő [I/O eszközhöz vagy fájlhoz. Eze- 
ken kívül azonban saját adatfolyamokat is létrehozhatunk, és ezek esetében nekünk kell 
megmondanunk, hogy mihez akarjuk azokat kötni. Az adatfolyamoknak fájlokhoz, illetve 
karakterláncokhoz való kötése elég általános feladat ahhoz, hogy a standard könyvtár köz- 
vetlenül támogassa. Az alábbi ábra a szabványos adatfolyam-osztályok viszonyrendszerét 
mutatja be: 
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ios base 
ios£- 
e eöetléeés . alma SZEN 
istreama2 ostreamáz 
istrigstream£2 ijstreamzz iostreama: ofstreamcz ostringstreamcz 
JÍstreamcz stringstreamcz 


Azok az osztályok, melyek neve után a €- jel szerepel, olyan sablonok, melyeknek para- 
métere egy karaktertípus. Ezek teljes neve a basic előtaggal kezdődik. A pontozott vonal 
virtuális bázisosztályt jelöl (415.2.49. 


A fájlok és a karakterláncok azon tárolók közé tartoznak, melyeket írásra és olvasásra is fel- 
használhatunk. Ezért ezekhez olyan adatfolyamokat határozhatunk meg, melyek a cc és 
a 55 műveleteket egyaránt támogatják. Az ilyen adatfolyamok bázisosztálya az iostream, 
amely az stid névtérhez tartozik és az Ciostream: fejállomány írja le: 


template cclass Ch, class Tr - char. traitsZCh: 5 
class basic iostream : public basic istreamzCh, Tr, public basic ostreamZCh, Tr: f 
bublic: 

explicit basic iostream(basic streambujzCh,Tr2" sb); 

virtual -basic iostreamO; 


J; 


typedef basic iostreamáchar?; iostream; 
typedef basic iostreamZwchar. t2 wiostream; 


Egy iostream írását és olvasását a streambuf objektumán (§21.6.4) végzett ki- és bemeneti 
tárműveletekkel vezérelhetjük. 


21.5.1. Fájlfolyamok 


A következő példában bemutatunk egy teljes programot, amely egy fájlt egy másikba má- 
sol. A fájlneveket parancssori paraméterekként lehet megadni: 
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finclude Sfstream: 
finclude ccstdlib: 


void error(const char? p, const char" p2 - ") 


( 
cerr ££ p cc !! cz p2 cc Mi; 
std::exit( DD; 

) 


int main(int argc, char?" argul 


( 


if (argc !- 3) error( "Hibás paraméterszám"); 


std::ifstream from(argul1)); // bemeneti fájlfolyam megnyitása 
if (from) errorCA bemeneti fájl nem nyitható meg", argul1)); 


std::ofstream to(argul2D; // kimeneti fájlfolyam megnyitása 
if (to) errorCA kimeneti fájl nem nyitható meg", argul2D; 


char ch; 
while (from.get(ch)) to.put(ch); 


if (from.eofoO 11 to) error( Váratlan esemény történt"); 


Egy fájlt olvasásra az ifstream osztály egy objektumának létrehozásával nyithatunk meg, pa- 
raméterként a fájl nevét megadva. Ugyanígy az o/stream osztály felhasználásával a fájlt írás- 
ra készíthetjük fel. Mindkét esetben a létrehozott objektum állapotának vizsgálatával ellen- 
őrizzük, hogy sikerült-e a fájl megnyitása. A basic ojstream az Sfstream: fejállományban 
a következőképpen szerepel: 


template cclass Ch, class Tr - char. traitsZCh: 5 
class basic ofstream : public basic ostreamzCh, Tr (f 
bublic: 

basic ojstreamO; 

explicit basic ofstream(const char? p, obenmode m - out); 


basic filebufzCh,Tr-? rdbufO const;  // mutató az aktuális átmeneti tárra (§21.6.4) 
bool is obenO const; 


void open(const char?" p, openmode m - out); 
void closeO; 
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A basic ifjstream nagyon hasonlít a basic ofstream osztályra, azzal a különbséggel, hogy 
a basic istream osztályból származik, és alapértelmezés szerint olvasásra nyithatjuk meg. 
Ezeken kívül a standard könyvtár biztosítja a basic jstream osztályt is, amely szintén hason- 
lít a basic ojstream-re, csak itt a bázisosztály a basic iostream, és alapértelmezés szerint ír- 
ható és olvasható is. 


Szokás szerint a leggyakrabban használt típusokhoz önálló típusnevek (typedef-ek) tartoznak: 


typedef basic ifstreamáchar? ifstream; 
typedef basic ojstreamáchar?; ofstream; 
typedef basic fstreamcchar? fstream; 


typedef basic ifstreamZwchar. t2 wifstream; 


typedef basic ofstreamZwchar. t2 wofstream; 
typedef basic fstreamZwchar. t2 wfstream; 


A fájlfolyamok konstruktorainak második paraméterében más megnyitási módokat is meg- 
adhatunk: 


class ios base f( 


bublic: 
Jat 
typedefmegvalósítás függő3 openmode; 
static obenmode app, // hozzáfűzés 
ate, // megnyitás és pozícionálás a fájl végére 
// (kiejtése: "at end") 
binary, // bináris I/O (a szöveges (text) mód 
// ellentéte) 
in, // megnyitás olvasásra 
out, // megnyitás írásra 
trunc; // fájl csonkolása O hosszúságúra 
Mas 


Az openmode konstansok konkrét értéke és jelentése a megvalósítástól függ, ezért ha rész- 
leteket szeretnénk megtudni, akkor saját fejlesztőrendszerünk és standard könyvtárunk le- 
írását kell elolvasnunk, vagy kísérleteznünk kell. A megjegyzésekből következtethetünk, 
hogy az egyes módoktól körülbelül mit várhatunk. Például egy fájlt megnyithatunk úgy, 
hogy minden, amit beleírunk, a végére kerüljön: 


ofstream mystream(name.c strO,ios base::app); 
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De megnyithatunk egy fájlt egyszerre írásra és olvasásra is: 


Jstream dictionary("concordance",ios base::in lios base::out); 


21.5.2. Adatfolyamok lezárása 


A fájlokat közvetlenül az adatfolyam close0 tagfüggvényének meghívásával zárhatjuk be: 


void fostreamk mystream) 


( 
Zs 


mystream.closeO; 


J 


Ennek ellenére az adatfolyam destruktora is elvégzi ezt a feladatot, így a close0 függvény 
meghívására akkor van csak szükség, ha a fájlt már azelőtt be kell zárnunk, mielőtt az adat- 
folyam hatóköréből kikerülnénk. 


Ez felveti a kérdést, hogy az adott fejlesztőkörnyezet hogyan biztosíthatja, hogy a cout, cin, 
cerr és clog adatfolyamok már első használatuk előtt létrejöjjenek és csak utolsó használa- 
tuk után záródjanak le. Természetesen az Ciostream: adatfolyam-könyvtár különböző vál- 
tozatai különböző módszereket alkalmazhatnak e cél eléréséhez. Végeredményben az, 
hogy hogyan oldjuk meg ezt a problémát, részletkérdés, amelyet nem kell és nem is szabad 
a felhasználó által láthatóvá tenni. Az alábbiakban csak egy lehetséges megoldást mutatunk 
be, amely elég általános arra, hogy különböző típusú globális objektumok 
konstruktorainak és destruktorainak lefutási sorrendjét rögzítsük. Egy konkrét megvalósítás 
ennél hatékonyabb megoldást is kínálhat a fordító és az összeszerkesztő (linker) egyedi le- 
hetőségeinek felhasználásával. 


Az alapötlet az, hogy egy olyan segédosztályt hozunk létre, amely számon tartja, hányszor 
építettük be az ciostream? fejállományt egy külön fordított forrásfájlba: 


class ios base::Init f 
static int count; 
bublic: 
InitO; 
ani; 
J; 
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namespace ( // az Siostream: állományban, egy másolat minden fájlban, 
ios base::Init — ioinit; // ahová ciostream:-et beépítik 


j 


int ios base::Init::count — 0; // valamelyik .c állományban 


Minden fordítási egység (49.1) deklarál egy-egy saját  ioinit nevű objektumot. Az — ioinit 
objektumok konstruktora az ios base::Init::count felhasználásával biztosítja, hogy az [/D 
könyvtár globális objektumainak kezdeti értékadása csak egyszer történjen meg: 


ios base::Init::InitO 


( 
if (count44 -- 0) f /" kezdőérték cout, cerr, cin stb. számára ?/ ) 


j 


Ugyanígy az ioinit objektumok destruktora az ios base::Init::count segítségével biztosít- 
ja az adatfolyamok lezárását: 


ios base::Init::-InitO 


( 
if (-count -- 0) f / felszámolja cout-ot (flush stb.), illetve a cerr-t, cin-t stb. "/ ) 


j 


Ez a módszer általánosan használható olyan könyvtárak esetében, melyekben globális objek- 
tumoknak kell kezdőértéket adni, illetve meg kell azokat semmisíteni. Az olyan rendszerek- 
ben, ahol a teljes program az elsődleges memóriában kap helyet futás közben, ez a módszer 
nem jelent teljesítményromlást. Ha azonban nem ez a helyzet, akkor jelentős veszteséget 
jelenthet, hogy a kezdeti értékadások miatt kénytelenek vagyunk a tárgykódokat (object fáj- 
lokatb) sorban beolvasni az elsődleges memóriába. Ha lehetséges, kerüljük el a globális objek- 
tumok használatát. Egy olyan osztályban, ahol minden művelet jelentős, érdemes lehet min- 
den függvényben elvégezni egy olyan ellenőrzést, mint amit az ios base::Init::count végez, 
ezzel biztosíthatjuk a kezdeti értékadásokat. Ez a megoldás azonban az adatfolyamok eseté- 
ben rendkívül költséges lenne. Egy olyan függvény számára, amely egyetlen karaktert ír ki 
vagy olvas be, egy ilyen ellenőrzés komoly többletterhelést jelentene. 


21.5.3. Karakterlánc-folyamok 


Az adatfolyamokat hozzáköthetjük karakterláncokhoz is. Ez azt jelenti, hogy az adatfolya- 
mok által kínált formázási lehetőségek felhasználásával karakterláncokat is írhatunk és ol- 
vashatunk. Az ilyen adatfolyamok neve siringstream, leírásukat az Csstream: fejállomány 
tartalmazza: 
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template cclass Ch, class Tr-char. traitsZCh: 5 
class basic stringstream : public basic iostreamzZCh, Tr: f 
bublic: 
explicit basic stringstream(ios base::openmode m - out lin); 
explicit basic stringstream(const basic stringcCh:£ s, obenmode m - out lin); 


basic stringZCh: strÓ const; // a karakterlánc másolatát veszi 
void str(const basic stringZCh:£ 5); // az értéket s másolatára állítja 


basic stringbufZCh, Tr: rdbujfÓ const; // mutató az aktuális átmeneti tárra 


J; 


A basic istringstream a basic stringstream osztályra hasonlít, azzal a különbséggel, hogy 
a basic istream osztályból származik, és alapértelmezés szerint olvasásra nyithatjuk meg. 
A basic ostringstream is a basic stringstream ,testvére", csak itt a bázisosztály 
a basic ostream, és alapértelmezés szerint írásra nyitjuk meg. 


Szokás szerint a leggyakrabban használt egyedi célú változatokhoz önálló típusnevek 
(typedef-ek) tartoznak: 


typedef basic istringstreamáchar? istringstream; 
typedef basic ostringstreamáchar? ostringstream; 
typedef basic stringstreamáchar? stringstream; 
typedef basic istringstreamZwchar. t2 wistringstream; 
typedef basic ostringstreamZwchar. t2 wostringstream; 
typedef basic stringstreamZwchar. t2 wstringstream; 


Az ostringstream objektumokat például üzenet-karakterláncok formázására használhatjuk: 


string compose(int n, const stringdz cs) 


( 


extern const char? std messagel[ [; 

ostringstream ost; 

ost ££ "erro(" ££ n cz ") " cz std message[n] cz " (user comment: " SZ cs ££ ); 
return ost.strO; 


A túlcsordulást ez esetben nem kell ellenőriznünk, mert az ost mérete az igények szerint nő. 
Ez a lehetőség különösen hasznos olyan esetekben, amikor a megkívánt formázási felada- 


tok bonyolultabbak annál, amit az általános, sorokat előállító kimeneti eszközök kezelni 
tudnak. 


A karakterlánc-folyamok kezdőértékét ugyanúgy értelmezi a rendszer, mint a fájlfolyamok 
esetében: 
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string compose2(int n, const string cs) // egyenértékű a composeO-zal 
( 
extern const char? std messagel [; 
ostringstream ost("hiba("ios base::ate); // a kezdeti karakterlánc végétől kezd írni 


ost ££ n cz ") " cz std messageln] cz " (felhasználói megjegyzés: " SZ cs SZ )); 
return ost.strO; 


Az istringstream egy olyan bemeneti adatfolyam, amely az adatokat a konstruktorban meg- 
adott karakterláncból olvassa (ugyanúgy, ahogy az i/filestream a megadott fájlból olvas): 


sinclude csstream: 


void word per. line(const string s) . // soronként egy szót ír ki 


( 
istringstream ist(5); 
string w; 
while (ist22w) cout ££ w cz Mt 


j 


int mainŐ 


( 


word per. line("Ha azt hiszed, a C54 nehéz, tanulj angolul"); 


J 


A kezdőértéket adó string bemásolódik az istringstream objektumba. A karakterlánc vége 
a bemenet végét is jelenti. 


Lehetőség van olyan adatfolyamok meghatározására is, melyek közvetlenül karaktertöm- 
bökből olvasnak, illetve oda írnak (§21.10I26D. Ez igen hasznos segítség, főleg, ha régebbi 
programokkal kell foglalkoznunk. Az ezen szolgáltatást megvalósító ostrstream és 
istrstream osztály már régebben bekerült a szabványos adatfolyam-könyvtárba. 


21.6. Ki- és bemeneti átmeneti tárak 


A kimeneti adatfolyamok vezérelve, hogy egy átmeneti tárba (putfterbe) írják a karaktere- 
ket, és azok egy kis idő múlva innen kerülnek át oda, ahova valójában írni akartuk azokat. 
Az átmeneti tárak osztályának neve streambuf(§21.6.4), melynek definíciója a cstireambuf: 
fejállományban szerepel. A különböző típusú szreambuf osztályok különböző tárolási mód- 
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szereket alkalmaznak. A legáltalánosabb megoldás az, hogy a streambuf egy tömbben tá- 
rolja a karaktereket mindaddig, amíg túlcsordulás nem következik be, és csak ilyenkor írja 
ki a teljes tömböt a megfelelő helyre. Tehát egy ostream objektumot az alábbi formában 
ábrázolhatunk: 





valódi cél 















ostream: 


Ms 


tellpO 
begin 
streambuf: ! current 








karakter átmeneti tár 











Az ostream-nek és a hozzá tartozó streambuf objektumnak ugyanazokat a sablonparamé- 
tereket kell használnia, és ezek határozzák meg a karakterek átmeneti tárában használt 
karaktertípust. 


Az istream osztályok nagyon hasonlóak, csak ott a karakterek az ellenkező irányba folynak. 
Az átmenetileg nem tárolt (unbuffered) [I/O olyan egyszerű ki- és bemenet, ahol az adatfo- 
lyam átmeneti tára azonnal továbbít minden karaktert, és nem várakozik addig, amíg meg- 
felelő számú karakter gyűlik össze a hatékony továbbításhoz. 


21.6.1. Kimeneti adatfolyamok és átmeneti tárolók 


Az ostream osztály számtalan különböző típusú érték karakterré átalakítását teszi lehetővé 
az alapértelmezéseknek (421.2.1) és a megadott formázási utasításoknak (421.4) megfelelő- 
en. Az ostream ezenkívül nyújt néhány olyan függvényt is, melyek közvetlenül a streambuf 
kezelésével foglalkoznak: 


template cclass Ch, class Tr - char. traitsZCh: 5 
class basic ostream : virtual public basic ioszCh, Tr: f 
bublic: 

MS 


explicit basic ostream(basic streambujzCh,Tr2? b); 


864 A standard könyvtár 


bpos type tellpO; // aktuális pozíció lekérése 
basic ostreamdé seekp(pos type); // aktuális pozíció beállítása 
basic ostreamdt seekp(off type, ios. base::seekdir); // aktuális pozíció beállítása 


basic ostreamg flushO; // átmeneti tár ürítése (a tényleges cél felé) 


basic ostreamkg operatorzá(basic streambujfzCh,Tr2? b); // írás b-ből 


J; 


Az ostream konstruktorában megadott strembuf paraméter határozza meg, hogy a kiírt ka- 
raktereket hogyan kezeljük és mikor legyenek ténylegesen kiírva a meghatározott eszköz- 
re. Például egy ostringcstream (§21.5.3) vagy egy o/stream (§21.5.1) létrejöttekor az ostream 
objektumnak a megfelelő streambuf(§21.6.4) megadásával adunk kezdőértéket. 


A seekpO függvények azt állítják be, hogy az ostream milyen pozícióra írjon. A bp utótag azt 
jelzi, hogy ez a pozíció az adatfolyamban a karakterek kiírására (puD szolgál. Ezek a függ- 
vények csak akkor működnek, ha az adatfolyam olyasvalamihez van kötve, amin a pozici- 
onálás értelmes művelet (tehát például egy fájlhoz). A bos tybetípus egy karakterhelyet áb- 
rázol a fájlban, míg az o/f type az ios base::seekdir változó által kijelölt helytől való eltérést 
jelöli: 


class ios base f( 


se 


typedef implementation defined seekdir; 

static const seekdir beg, // keresés a fájl elejétől 
cur, // keresés az aktuális pozíciótól 
end; // keresés a fájl végétől 

szi 


J; 


Az adatfolyamok kezdőpozíciója a O, így a fájlokat nyugodtan képzelhetjük n karakterből 
álló tömböknek: 


int fojfstreamkg fout) // fout valamilyen fájlra hivatkozik 
( 
Jfout.seekpC109; 
fout cz // karakter kiírása és pozíció mozgatása (31) 


Jfout.seekp(-2,ios base::cur); 
fout edu 


j 
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A fenti programrészlet egy 7 karaktert helyez a /filef10/ pozícióra és egy " szimbólumot 
a filel9/] helyre. Az egyszerű istream és ostream osztály esetében ilyen közvetlen hozzáfé- 
résre nincs lehetőségünk (lásd §21.10[13]. Ha megpróbálunk a fájl eleje elé vagy vége után 
írni, az adatfolyam badőÓ állapotba kerül (421.3.3). 

A flushO művelet lehetővé teszi a programozó számára, hogy a túlcsordulás megvárása nél- 
kül ürítse ki az átmeneti tárat. 


Lehetőség van arra is, hogy a cc operátor segítségével egy sireambuf objektumot közvetle- 
nül a kimeneti adatfolyamba írjunk. Ez elsősorban az [/O rendszerek készítőinek hasznos 
segítség. 


21.6.2. Bemeneti adatfolyamok és átmeneti tárolók 


Az istream elsősorban olyan műveleteket kínál, melyek segítségével karaktereket olvasha- 
tunk be és alakíthatunk át különböző típusú értékekre (§21.3.19. Ezenkívül azonban nyújt 
néhány olyan szolgáltatást is, melyekkel közvetlenül a streambuf objektumot érhetjük el: 


template cclass Ch, class Tr - char. traitsZCh: 5 
class basic istream : virtual public basic ioszCh, Tr: f 
public: 

1 sasó 


explicit basic istream(basic streambujzCh Tr2? b); 


bos type tellgO; // aktuális pozíció lekérdezése 
basic istreamg seekg(pos typeJ; // aktuális pozíció beállítása 
basic istreamáét seekg(off type, ios base::seekdir); // aktuális pozíció beállítása 
basic istream£ putback(Ch c); // c visszarakása az átmeneti tárba 
basic istreamdt ungetO; // putback alkalmazása a legutóbb beolvasott 

// karakterre 
int type peekO; // a következő beolvasandó karakter 
int syncO; // átmeneti tár ürítése (flush) 
basic istream£ operator:P(basic streambujzCh Tr2? b); // olvasás b-be 


basic istreamg get(basic streambujzcCh Tr-k b, Ch t - Tr::-newlineO); 


streamsize readsome(Ch"? p, streamsizen); — // legfeljebb n karakter beolvasása 


3 
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A pozicionáló függvények ugyanúgy működnek, mint az ostream osztálybeli megfelelőik 
(421.6.19. A g utótag azt jelzi, hogy ez a pozíció a karakterek beolvasásának (geD helye. A p 
és a g utótagokra azért van szükség, mert készíthetünk olyan ijostream osztályt is, melynek 
bázisosztálya az istream és az ostream is, és ilyenkor is meg kell tudnunk különböztetni az 
írási és az olvasási pozíciót. 


A putbackO függvények azt teszik lehetővé, hogy a program visszategye az adatfolyamba 
azokat a karaktereket, amelyekre egyelőre nincs szüksége, de később még fel szeretnénk 
dolgozni. Erre a §21.3.5 pontban mutattunk példát. Az ungetO függvény a legutoljára beol- 
vasott karaktert teszi vissza az adatftolyamba. Sajnos a bemeneti adatfolyamok ilyen , vissza- 
görgetése" nem mindig lehetséges. Például ha megpróbáljuk visszaírni az utolsó előtti beol- 
vasott karaktert is, az ios base::failbit hibajelzóő bekapcsolódik. Csak abban lehetünk 
biztosak, hogy egyetlen, sikeresen beolvasott karaktert vissza tudunk írni. A beekO beolvas- 
sa a következő karaktert, de azt az átmeneti tárban hagyja, így újra beolvashatjuk. Tehát 
a c-peekO utasítás egyenértékű a (c-get0, unget, c) és a (putback(c-get0), c) parancs-so- 
rozatokkal. Figyeljünk rá, hogy a failbit bekapcsolása kivételt válthat ki (421.3.09. 


Az istream-ek átmeneti tárának azonnali kiürítését (flushing) a syncO paranccsal kénysze- 
ríthetjük ki, de ezt a műveletet sem mindig használhatjuk biztonságosan. Bizonyos típusú 
adatfolyamokban ehhez újra kellene olvasnunk a karaktereket az eredeti forrásból, ami 
nem mindig lehetséges vagy hibás bemenetet eredményezhet. Ezért a syncO 0 értéket ad 
vissza, ha sikeresen lefutott, és —7-t, ha nem. Ha a művelet sikertelen volt, erre az 
ios base::badbit(§21.3.3) is felhívja a figyelmünket. A badbit értékének megváltozása is ki- 
vételt válthat ki (421.3.69. Ha a syncO függvényt olyan átmeneti tárra használjuk, amely egy 
ostream objektumhoz kapcsolódik, akkor az átmeneti tár tartalma a kimenetre kerül. 


A 55 és a get) műveletnek is van olyan változata, mely közvetlenül az átmeneti tárba ír, de 
ezek is elsősorban az [/O szolgáltatások készítőinek jelentenek hasznos segítséget, hiszen 
az adatfolyamok átmeneti tárainak közvetlen elérésére csak nekik van szükségük. 


A readsomeO függvény egy alacsonyszintű művelet, mellyel a programozó megállapíthat- 
ja, hogy van-e az adatfolyamban beolvasásra váró karakter. Ez a szolgáltatás akkor nagyon 
hasznos, ha nem akarunk a bemenet megérkezésére várni (például a billentyűzetről). Lásd 
még: in avail0 (§21.6.4). 


21.6.3. Az adatfolyamok és az átmeneti tárak kapcsolata 


Az adatfolyam és a hozzá tartozó átmeneti tár közötti kapcsolatot az adatfolyamok basic ios 
osztálya tartja fenn: 
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template cclass Ch, class Tr - char. traitsZCh: 5 
class basic ios : public ios base f 
public: 

Úszás 


basic streambujcCh,Tr2? rdbufO const; // mutató az átmeneti tárra 
// az átmeneti tár beállítása, clearO, és mutató visszaadása a régi tárra 
basic streambujáCh,Tr2? rdbuf(basic streambujzcCh,Tr2" b); 


locale imbue(const localekg loc); // helyi sajátosságok beállítása (és 
// a régi érték kiolvasása) 


char narrou(char. type c, char d) const; // char érték char. type típusú c-ből 
char. type widen(char c) const; // char. type érték a c char-ból 
Ma 

brotected: 
basic iosO; 
void init(basic streambufzZCh,Tr2" b); // a kezdeti átmeneti tár beállítása 


97 


Azon kívül, hogy lekérdezhetjük és beállíthatjuk az adatfolyam streambuf objektumát 
(§21.6.4), a basic ios osztályban szerepel az imbueO függvény is, mellyel beolvashatjuk és 
átállíthatjuk az adatfolyam helyi sajátosságokat leíró locale objektumát (421.79. Az imbueO 
függvényt az ios base (421.7.1) objektumra, a pubimbueO függvényt az átmeneti tárra 
(§21.6.4) kell meghívnunk. 


A narroug és a widenO függvény segítségével az átmeneti tár karaktertípusát konvertál- 
hatjuk char típusúra, vagy fordítva. A narrow(c,d) függvényhívás második paramétere az 
a char, amelyet akkor szeretnénk visszakapni, ha a c-ben megadott char. type értéknek 
nincs char megfelelője. 


21.6.4. Adatfolyamok átmeneti tárolása 


Az [/D műveletek meghatározása fájltípus említése nélkül történt, de nem kezelhetünk min- 
den eszközt ugyanúgy az átmeneti tárolásnál. Egy karakterlánchoz kötött ostream objek- 
tumnak (421.5.3) például másféle tárolásra van szüksége, mint egy fájlhoz kötött (421.5.1) 
kimeneti adatfolyamnak. Ezeket a problémákat úgy oldhatjuk meg, hogy a különböző adat- 
folyamokhoz a kezdeti értékadáskor különböző típusú átmeneti tárakat rendelünk. Mivel 
a különböző típusú tárak ugyanazokat a műveleteket biztosítják, az ostream osztálynak 
nem kell különbözőnek lennie hozzájuk. Minden átmeneti tár a stireambuf osztályból szár- 
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mazik. A streambuf virtuális függvényeket nyújt azokhoz a műveletekhez, melyek a külön- 
böző tárolási módszereknél eltérőek lehetnek. Ilyenek például a túlcsordulást és az alul- 
csordulást kezelő eljárások. 


A basic streambuf osztály két felületet tesz elérhetővé. A nyilvános (public) felület elsősor- 
ban azoknak hasznos, akik olyan adatfolyam-osztályokat akarnak elkészíteni, mint az 
istream, az ostream, az fstream vagy a stringstream. A védett (protected) felület célja azon 
programozók igényeinek kiszolgálása, akik új tárolási módszert akarnak bevezetni, vagy új 
bemeneti forrásokat és kimeneti célokat akarnak kezelni. 


A streambuf osztály megértéséhez érdemes először megismerkednünk az alapját képező át- 
meneti tárterület modellel, amelyet a védett felület biztosít. Képzeljük el, hogy a szreambuf 
objektumnak van egy kimeneti területe, amelybe a CZ operátor segítségével írhatunk, és 
van egy bemeneti területe, amelyből a 5: operátor olvas. Mindkét területet három mutató ír 
le: egy a kezdőpontra, egy az aktuális pozícióra, egy pedig az utolsó utáni elemre mutat. 
Ezeket a mutatókat függvényeken keresztül érhetjük el: 


template cclass Ch, class Tr - char. traitsZCh: 5 
class basic streambuf f 


brotected: 
Ch": ebackO const; // a bemeneti tár kezdete 
Ch" gptrO const; // következő karakter (a következő olvasás innen történik) 
Ch" egptrO const; // a bemeneti tár utolsó eleme utánra mutat 
void gbump(int n); // n hozzáadása gptrO-hez 
void setg(Ch" begin, Ch? next, Ch" end); // ebackO, gptrO, és egptrO beállítása 
Ch" pbaseO const; // a kimeneti tár kezdete 
Ch" pptrO const; // a következő üres karakter (a következő kiírás ide történik) 
Ch? epptrO const; // a kimeneti tár utolsó eleme utánra mutat 
void pbump(Cint n); // n hozzáadása pptrO-hez 
void setp(Ch" begin, Ch" end); // pbaseO és pptrO begin-re, epptrO end-re állítása 
IL etet 


J; 
Egy karaktertömbre a setgO és a setpO függvény segítségével megfelelően beállíthatjuk 
a mutatókat. A programozó a bemeneti területet a következő formában érheti el: 


template cclass Ch, class Tr - char. traitsZCh: 5 
basic streambujzCh,Tr:::int type basic streambujfzCh, Tr2::snextcO) 
// az aktuális karakter átlépése, a következő beolvasása 


( 
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if (12egptrO-gptrO) ( // ha legalább két karakter van az átmeneti tárban 
gbump(1; // az aktuális karakter átlépése 
return Tr::to int typeCtgptrO);  // az új aktuális karakter visszaadása 


j 

if ( 1--egbtrŐ-gptrO ) ( // ha pontosan egy karakter van az átmeneti tárban 
gbump(1; // az aktuális karakter átlépése 
return underflowO; 

J 


// az átmeneti tár üres (vagy nem használt), próbáljuk feltölteni 

if (Tr:eg int typel(uflowO, Tr::eofO) return Tr::eofO; 

if (OZeptrO-gptrO) return Tr::to int typeCtgptrO); // az új aktuális karakter 
visszaadása 

return underflow; 


j 


Az átmeneti tárat a gptrO-en keresztül érjük el, az egptrO a bemeneti terület határát jelzi. 
A karaktereket a valódi forrásból az uflowO és az underflowO olvassák ki. 
A traits tybpe::to int typeO meghívása biztosítja, hogy a kód független lesz az éppen hasz- 
nált karaktertípustól. A kód többféle típusú adatfolyam-tárral használható és figyelembe ve- 
szi azt is, hogy az ujflowO és az underflowO virtuális függvények (a setgO segítségével) új 
bemeneti területet is meghatározhatnak. 


A streambuf nyilvános felülete a következő: 


template cclass Ch, class Tr - char. traitsZCh: 2 
class basic streambuf f 
public: 

// szokásos típus-meghatározások (§21.2.1 


virtual -basic streambufO; 


locale pubimbue(const locale loc); // locale beállítása (és régi kiolvasása) 
locale getlocO const; // locale kiolvasása 


basic streambuf?" pubsetbu((Ch" p, streamsize n); // átmeneti tárterület beállítása 
bos type pubseekoff(off type off, ios base::seekdir way, // pozíció (§21.6.1 


ios base::obenmode m - ios base::in lios base::out; 
bos type pubseekpos(pos type p, ios base::obenmode m - ios base::in lios base::out); 


int pubsyncO; // sync0), lásd §21.6.2 
int type snextcO; // aktuális karakter átlépése, a következő kiolvasása 
int type sbumpcO; // gptrO léptetése 1-el 


int type sgetcO; // az aktuális karakter beolvasása 
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streamsize sgetn(Ch? p, streamsize n); // beolvasás pl0J. pln-1/-be 

int type sputbackc(Ch c); // c visszahelyezése az átmeneti tárba (§21.6.2) 
int type sungetcO; // az utolsó karakter visszahelyezése 

int type sputc(Ch c); // c kiírása 

streamsize sputn(const Ch" p, streamsize n); // pl0l. pln-1] kiírása 
streamsize in avail0; // bemenet rendben? 

1 aa 


A nyilvános felület olyan függvényeket tartalmaz, melyekkel karaktereket helyezhetünk az 
átmeneti tárba, illetve karaktereket vehetünk ki onnan. Ezek a függvények általában na- 
gyon egyszerűek és helyben kifejtve (inline) is fordíthatók, ami a hatékonyság szempontjá- 
ból kulcsfontosságú. 


Azok a függvények, melyek tevékenysége függ a használt tárolási módtól, a védett felület 
megfelelő eljárását hívják meg. A pbubsetbufO) például a setbufO függvényt hívja meg, ame- 
lyet a leszármazott osztály felülír az átmenetileg tárolt karakterek számára való memóriafog- 
laláshoz. Tehát az olyan műveletek megvalósítására, mint a setbufO), két függvény szolgál, 
műveleteket, miköz- 
ben a felhasználó függvényét meghívja. A virtuális függvény meghívását egy try blokkba 
helyezhetjük, és elkaphatjuk a felhasználói kód által kiváltott kivételeket is. 


An 


ami azért praktikus, mert így egy ijostream is végezhet , rendfenntartó 


Alapértelmezés szerint a setbuj(O,0) az átmeneti tárolás hiányát jelenti, míg a setbuf(p,n) 
a pl0J,. . ., blín-1] tartomány használatát írja elő a karakterek átmeneti tárolására. 


Az in avail0 függvény meghívásával azt állapíthatjuk meg, hány karakter áll rendelkezé- 
sünkre az átmeneti tárban. Ennek vizsgálatával elkerülhetjük a bemenetre való várakozást. 
Amikor olyan adatfolyamból olvasunk, amely a billentyűzethez kapcsolódik, a cin.get(c) 
akár addig várakozik, amíg a felhasználó vissza nem tér az ebédjéről. Egyes rendszerekben 
és alkalmazásokban érdemes felkészülnünk erre a lehetőségre: 


if (cin.rdbufO-:in avail0) f / get nem fog lefagyni 
cin.get(c); 
// csinálunk valamit 


j 


else ( // getO lefagyhat 
// valami mást csinálunk 


j 
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Vigyázzunk e lehetőség használatakor, mert néha nem könnyű annak megállapítása, hogy 
van-e beolvasható bemenet. Az in avail0 adott változata esetleg O értéket ad vissza, ha egy 
bemeneti műveletet sikeresen végrehajthatunk. 


A nyilvános felület mellett — amelyet a basic istream és a basic ostream használ — 
a basic streambuf egy védett felületet is kínál, mellyel az adatfolyamok átmeneti tárainak 
elkészítését segíti, és azokat a virtuális függvényeket vezeti be, amelyek meghatározzák az 
átmeneti tárolás irányelveit: 


template cclass Ch, class Tr - char. traitsZCh: 5 
class basic streambuf ( 
protected: 
VÜgGS 
basic streambufO; 
virtual void imbue(const locale loc); // locale beállítása 
virtual basic streambuf" setbu((Ch" p, streamsize n); 
virtual pos type seekofk(off- type ojf, ios base::seekdir way, 
ios base::opbenmode m - ios base::in lios base::out; 
virtual pos type seekpos(pos type p, 
ios base::openmode m - ios base::in lios base::out); 


virtual int syncO; // syncO, lásd §21.6.2 


virtual int showvmanycO; 


virtual streamsize xsgetn(Ch? p, streamsize n); // n karakter beolvasása 

virtual int type underflowO; // az olvasási terület üres, eof vagy 
// karakter visszaadása 

virtual int type uflowO; //az olvasási terület üres, eof vagy 


// karakter visszaadása, gptrO növelése 
virtual int. type pbackfailGint. type c — Tr::eofO); // a putback nem járt sikerrel 


virtual streamsize xspbutn(const Ch" p, streamsizen); /n karakter kiírása 
virtual int type overflou(int type c — Tr::eofO); // kiíró terület megtelt 
Fő 


Az underfloug és az ujlowO függvény szolgál arra, hogy a következő karaktereket beolvas- 
suk a tényleges bemeneti forrásról, ha az átmeneti tár üres. Ha az adott forráson nincs beol- 
vasható bemenet, az adatfolyam eof állapotba (421.3.3) kerül. Ha ez nem vált ki kivételt, 
a traits type::cofO értéket kapjuk vissza. A gptrO-t a visszaadott karakter után az uflowO nö- 
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veli, az underflowO viszont nem. A rendszerben általában nem csak azok az átmeneti tárak 
vannak, amelyeket az iostream könyvtár hoz létre, így akkor is előfordulhatnak átmeneti tá- 
rolás miatti késlekedések, amikor átmenetileg nem tárolt adatfolyamot használunk. 


Az overflowO függvény akkor fut le, amikor az átmeneti tár megtelik, és ez továbbítja a ka- 
raktereket a kimenet valódi célállomására. Az overflow(c) utasítás az átmeneti tár tartalmát 
és a c karaktert is kiírja. Ha a célállomásra nem lehet több karaktert írni, az adatfolyam eof 
állapotba kerül (§21.3.3). Ha ez nem okoz kivételt, a traits type::cofO értéket kapjuk. 


A showmanycO -— , show how many characters", , nondd meg, hány karakter" — egy igen ér- 
dekes függvény. Célja az, hogy a felhasználó lekérdezhesse, hány karaktert tudunk , gyor- 
san" beolvasni, azaz az operációs rendszer átmeneti tárainak kiürítésével, de a lemezről va- 
ló olvasás megvárása nélkül. A szowmanycO függvény - 1] értéket ad vissza, ha nem tudja 
garantálni, hogy akár egy karaktert is be tudnánk olvasni a fájlvége jel megérkezése előtt. 
Ez az eljárás (szükségszerűen) elég alacsony szintű, és nagymértékben függ az adott meg- 
valósítástól. Soha ne használjuk a szowmanycO függvényt fejlesztőrendszerünk dokumen- 


Alapértelmezés szerint minden adatfolyam a globális helyi sajátosságoknak (global locaD 
megfelelően (421.7) működik. A pubimbue(doc) vagy az imbue(loc) függvény meghívásá- 
val az adatfolyamot a /oc objektumban megfogalmazott helyi sajátosságok használatára uta- 
síthatjuk. 


Az adott adatfolyamhoz használt szreambuf osztályt a basic streambujf osztályból kell szár- 
maztatnunk. Ebben kell szerepelnie azoknak a konstruktoroknak és kezdőérték-adó függvé- 
nyeknek, melyek a streambuf objektumot a karakterek valódi forrásához vagy céljához kötik, 
és ez írja felül a virtuális függvényeket az átmeneti tárolás módjának megvalósításához: 


template cclass Ch, class Tr - char. traitsZCh: 5 
class basic filebuf : public basic streambujzCh Tr: f 
bublic: 

basic filebufO; 

virtual -basic filebufO; 


bool is openO const; 
basic filebuf" open(const char? p, ios base::openmode mode); 
basic filebuf" closeO; 


brotected: 
virtual int showmanycO; 
virtual int type underflowO; 
virtual int type uflowO; 
virtual int type pbackfail(int type c — Tr::eofO; 
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virtual int type overflouw(Cint type c — Tr::eofO); 


virtual basic streambujcCh,Tr2? setbu(Ch? p, streamsize n); 
virtual pos type seekofk(off- type ojf, ios base::seekdir way, 

ios base::obenmode m - ios base::in lios base::out; 
virtual pos type seekpos(pos type p, 

ios base::obenmode m - ios base::in lios base::out; 
virtual int syncO); 
virtual void imbue(const localeg loc); 


vő 


Az átmeneti tárak kezelésére használt függvények változatlan formában a basic streambuf 
osztályból származnak. Csak a kezdeti értékadásra és a tárolási módszerre ható függvénye- 
ket kell külön megadnunk. 


Szokás szerint a leggyakoribb osztályokat és , széles" megfelelőiket külön typedef-ek teszik 
könnyen elérhetővé: 


typedef basic streambujáchar: streambuj; 
typedef basic stringbufáchar?: stringbuj; 
typedef basic filebufcchar? filebuf; 


typedef basic streambujáwchar. t2 wstreambuj; 
typedef basic stringbufcwchar. t2 wstringbujf; 
typedef basic filebufSwchar. t2 wfilebuj; 


21.7. Helyi sajátosságok 


A locale egy olyan objektum, amely a karakterek betűk, számok stb. szerinti osztályozásá- 
nak módját adja meg, illetve a karakterláncok rendezési sorrendjét és a számok megjelené- 
si formáját kiíráskor és beolvasáskor. Az iostream könyvtár általában automatikusan hasz- 
nál egy általános /ocale objektumot, amely biztosítja néhány nyelv és kultúra szokásainak 
betartását. Ha ez megfelel céljainknak, nem is kell foglalkoznunk /ocale objektumokkal. Ha 
azonban más szokásokat akarunk követni, akkor az adatfolyam viselkedését úgy változtat- 
hatjuk meg, hogy lecseréljük a hozzá kötött /ocale objektumot. 
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Az std névtérhez tartozó /ocale osztályt a clocale: fejállomány írja le: 


class locale ( //a teljes deklarációt lásd §D.2 
bublic: 

Mas 

locale0 throwO; // az aktuális globális locale másolata 


explicit locale(const char" name);  // locale létrehozása C stílusú locale név alapján 
basic stringcchar: nameO const;  // a használt locale neve 


localerconst localed ) throwO; // locale másolása 
const locale operator-(const localek ) throwO; // locale másolása 


static locale globakconst localek);  // a globális locale beállítása 
// (az előző érték kiolvasása) 
static const localeg classicO; // a C által meghatározott locale 


J; 


A helyi sajátosságok legközönségesebb használata, amikor egy locale objektumot egy má- 
sikra kell cserélnünk: 


void JO 
( 
std::locale locC"POSIX"); // szabványos POSIX locale 
cin.imbue(loc); // cin használja loc-ot 
V/áES 
cin.imbue(std::localeO); // cin visszaállítása az alapértelmezett (globális) 


// locale használatára 


Az imbueg függvény a basic ios (421.7.1) osztály tagja. 


Láthatjuk, hogy néhány, viszonylag szabványos /ocale objektum saját karakterlánc-neveket 
használ. Ezeket az elnevezéseket a C nyelv is használja. 


Elérhetjük azt is, hogy a C4- minden újonnan készített adatftolyamhoz automatikusan az ál- 
talunk megadott /ocale objektumot használja: 


void g(const localek loc - localeO) // alapértelmezés szerint az aktuális 
// globális locale használata 
( 
locale old global - locale::global(loc); // legyen loc az alapértelmezés 


Ma 


j 
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A globális /ocale objektum átállítása nincs hatással a már létező adatftolyamokra, mert azok 
továbbra is a globális /ocale régi értékét használják. Ez vonatkozik például a cin, cout stb. 
adatfolyamra is. Ha ezeket is meg akarjuk változtatni, közvetlenül az imbueO függvényt kell 
használnunk. 


Azzal, hogy egy adatfolyamhoz új locale objektumot rendelünk, több helyen is megváltoz- 
tatjuk arculatát, viselkedését. A locale osztály tagjait közvetlenül is használhatjuk, új helyi sa- 
játosságok meghatározására vagy a régiek bővítésére. A locale arra is használható, hogy be- 
állítsuk a pénzegységek, dátumok stb. megjelenési formáját ki- és bemenetkor (§21.10[25D, 
vagy a különböző kódkészletek közötti átalakítást. A helyi sajátosságok használatának elvét, 
illetve a locale és facet (arculat, viselkedés) osztályokat a ,D" függelék írja le. A C stílusú 
locale meghatározása a cclocale: és a clocale.h: fejállományokban található. 


21.7.1. Adatfolyam-visszahívások 


Néha a programozók az adatfolyamok állapotleírását bővíteni akarják. Például elvárhatjuk 
egy adatfolyamtól, hogy , tudja", milyen formában kell egy komplex számot megjeleníteni: 
polár- vagy Descartes-koordinátarendszerben. Az ios base osztályban szerepel az xallocO 
függvény, mellyel az ilyen egyszerű állapotinformációk számára foglalhatunk memóriát. 
Az xallocO által visszaadott érték azt a két memóriaterületet adja meg, amelyet az iwordO 
és a bpwordO függvénnyel elérhetünk: 


class ios base ( 


bublic: 
1 si 
-ios baseO; 
locale imbue(const localek loc); // locale kiolvasása és beállítása, lásd §D.2.3 
locale getlocO const; // locale kiolvasása 
static int xallocO; // egy egész és egy mutató lefoglalása (mindkettő 0 
// kezdőértékkel) 
longk iwordCint i); // az iword() egész elérése 
voidtk pword(int 1); // a pword(i) mutató elérése 
// visszahívások 
enum event f( erase event, imbue event, copyfjmt event ); // eseménytípusok 


typedef void ("event callback)(event, ios baseg, int i); 
void register. callback(event callback f, int i); // f hozzárendelése word())-hez 


); 
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A felhasználóknak és a könyvtárak készítőinek néha szükségük van arra, hogy értesítést 
kapjanak az adatfolyam állapotának megváltozásáról. A register. callbackO eljárás segítsé- 
gével a függvényeket , bejegyezhetjük", és azok akkor futnak le, amikor a nekik kijelölt 
, esemény" bekövetkezik. Tehát például az imbueO, a cobpyjmtO vagy a -ios baseO függ- 
vény meghívása maga után vonhatja egy bejegyzett függvény lefutását, amely sorrendben 
az imbue event, a cobyfmt event, illetve az erase event eseményt figyeli. Amikor az állapot 
megváltozik, a bejegyzett függvény a register. callbackO függvényben megadott i paramé- 
tert kapja meg. 


Ez a tárolási és visszahívási eljárás meglehetősen bonyolult, tehát csak akkor használjuk, ha 
feltétlenül szükségünk van az alacsonyszintű formázási szolgáltatások kibővítésére. 


21.8. C stílusú ki- és bemenet 


Mivel a C és a Cst kódokat gyakran keverik, a C-- adatfolyamon alapuló ki- és bemeneti 
eljárásait sokszor együtt használjuk a C nyelv printfO függvénycsaládját használó [/O rend- 
szerrel. A C stílusú [/D függvények a ccsidio: és az cstdio.h: fejállományban találhatók. 
Mivel a C függvények szabadon meghívhatók a C-t- programokból, sok programozó szíve- 
sebben használja a megszokott C ki- és bemeneti szolgáltatásokat, de még ha az adatfolya- 
mokon alapuló [/O eljárásokat részesítjük is előnyben, néha akkor is találkozni fogunk C 
stílusú megoldásokkal. 


A C és a Cs stílusú be- és kimenet karakterszinten keverhető. Ha a sync with stdioO függ- 
vényt meghívjuk a legelső adatfolyam alapú [/D művelet előtt, akkor a C és a C-t stílusú 
eljárások ugyanazokat az átmeneti tárakat fogják használni. Ha az első adatfolyam művelet 
előtt a sync with stdio(false) parancsot adjuk ki, az átmeneti tárakat a rendszer biztosan 
nem fogja megosztani, így egyes esetekben növelhetjük a teljesítményt: 


class ios base ( 
VAKES 


static bool sync with stdio(bool sync - true); // kiolvasás és beállítás 


J; 


Az adatfolyam elvű kimeneti függvények legfőbb előnye a C standard könyvtárának 
brintfO függvényével szemben, hogy az adatfolyam-függvények típusbiztosak és egységes 
stílust biztosítanak a különböző objektumok megadására, legyen azok típusa akár beépített, 
akár felhasználói. 
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A C általános kimeneti függvényei formázott kimenetet állítanak elő, melyben a megadott 
paraméterek sorozatának megjelenését a format formázási karakterlánc határozza meg: 


int printfconst char?" format ...); // írás az stdout-ra 
int fprintfFILE", const char" format ...); // írás "file"-ba (stdout, stderr) 
int sprintf(char" p, const char? format ...); // írás ploJ ... stb.-re 


A formázási karakterlánc kétfajta elemet tartalmazhat: sima karaktereket, amelyeket a rend- 
szer egyszerűen a kimeneti adatfolyamba másol, illetve átalakítás-meghatározásokat 
(conversion-specification), melyek mindegyike egy paraméter átalakítását és kiírását vezérli. 
Az átalakítás-meghatározásokat a 96 karakterrel kell kezdeni: 


brintf( Jelen volt 96d személy." no of members); 


Itt a 90d azt határozza meg, hogy a no of members változót int értékként kell kezelni és 
a megfelelő decimális számjegyek kiírásával kell megjeleníteni. 
Ha a no of members--127, akkor a megjelenő eredmény a következő lesz: 


Jelen volt 127 személy. 


Az átalakítás-meghatározásokat igen sokféleképpen megadhatjuk és nagyfokú rugalmassá- 
got biztosítanak. A 96 karaktert követően az alábbi jelek állhatnak: 


- . A nem kötelező mínuszjel azt írja elő, hogy a rendszer a megadott mezőben az át- 
alakított értéket balra igazítsa. 

t A nem kötelező pluszjel használata azt eredményezi, hogy az előjeles típusú érté- 
kek mindig - vagy - előjellel fognak megjelenni. 

0 A nem kötelező nulla jelentése: a mezőszélesség feltöltésére numerikus értékek 
esetén 0 karakterekkel történik. Ha a - vagy a pontosság megadott, akkor a 0 
előírást figyelmen kívül hagyjuk. 

zi A szintén nem kötelező é azt jelenti, hogy a lebegőpontos értékek mindenképpen 
tizedesponttal együtt jelennek meg, függetlenül attól, hogy utána esetleg csak 0 
számjegyek állnak; hogy a lezáró nullák is megjelennek; illetve hogy az oktális szá- 
mok előtt egy 0 karakter, hexadecimális számok előtt pedig a 0x vagy a 0X 
karakterpár jelenik meg. 

d Amnem kötelező számjegysorozat a mező szélességét határozza meg. Ha az átalakí- 
tott érték kevesebb karaktert tartalmaz, mint a mező szélessége, akkor annak bal 
oldalán Gilletve balra igazítás esetén a jobb oldalán) üres karakterek jelennek meg 
a megfelelő szélesség elérése érdekében. Ha a mezőszélesség megadását 0 karak- 
terrel kezdjük, a szélességnövelő karakterek szóköz helyett nullák lesznek. 
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A nem kötelező pont kiírásával választhatjuk el a mezőszélességet megadó értéket 
a következő számjegy-sorozattól. 

Újabb, nem kötelező számjegy-sorozat. A pontosságot határozza meg, azaz e és f 
átalakítás esetén a tizedes pont után megjelenő számjegyek számát, karakterláncok 
esetében pedig a megjelenítendő karakterek legnagyobb számát. 

A mezőszélesség vagy a pontosság konkrét megadása helyett használhatjuk a " ka- 
raktert, melynek hatására a következő paraméterben szereplő egész érték adja meg 
a kívánt értéket. 

A nem kötelező ? karakter azt jelzi, hogy a következő d, o, x vagy u egy short int 
paraméterre vonatkozik. 

A nem kötelező ! karakter azt jelzi, hogy a következő d, o, x vagy u egy long int 
paraméterre vonatkozik. 

Azt jelzi, hogy a 90 karakter kiírandó. Paramétert nem használ fel. 

Az átalakítás típusát jelző karakter. Az átalakító karakterek és jelentéseik 

a következők: 

Egész érték, amit tízes számrendszerben kell megjeleníteni. 

Egész érték, amit tízes számrendszerben kell megjeleníteni. 

Egész érték, amit nyolcas számrendszerben kell megjeleníteni. 

Egész érték, amit tizenhatos számrendszerben kell megjeleníteni, 0x kezdettel 
Egész érték, amit tizenhatos számrendszerben kell megjeleníteni, 0X kezdettel. 
Egy float vagy egy double paramétert kell tízes számrendszerbeli értékké 
alakítani a /-/ddd.ddd formátummal. A tizedespont után álló számjegyek szá- 
mát a megadott paraméter pontossága határozza meg. Ha szükség van rá, az 
értéket a rendszer kerekíti. Ha pontosság nincs megadva, 6 számjegy jelenik 
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meg; ha pontosságként 0 értéket adunk meg és a / jelet nem használjuk, 
a tizedesjegyek nem íródnak ki. 

e Egy float vagy double paramétert alakít tízes számrendszerbeli alakjára a tu- 
dományos /-/d.ddde--dd vagy a (-/d.ddde-dd alakra, ahol a tizedespont előtt 
pontosan egy jegy szerepel, míg a tizedespont után álló számjegyek számát 
az adott paraméter pontosság-meghatározása adja meg. Ha szükséges, az ér- 
téket a rendszer kerekíti. Ha pontosság nincs megadva, az alapértelmezett 
érték 6 lesz; ha a pontosság nulla és a é jelet nem használtuk, sem a tizedes- 
pont, sem az utána álló számjegyek nem jelennek meg. 

E Nagyon hasonlít az e-re, de a kitevő jelölésére ez a forma nagy E betűt használ. 

g Ajloatvagy double típusú paramétert d, /; vagy e stílusban írja ki, aszerint, 
hogy melyik biztosítja a legnagyobb pontosságot a lehető legkisebb területen. 

G Ugyanaz, mint a g, de a kitevő jelölésére a nagy E betűt használja. 

Karakter paramétert jelenít meg. A nullkaraktereket figyelmen kívül hagyja. 

Az így átvett paraméter egy karakterlánc (karakterre hivatkozó mutató). 


a 
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A karaktereket addig másolja a kimenetre, amíg a nullkaraktert, vagy a pon- 
tosság-meghatározásban meghatározott karakterszámot el nem éri. Ha 
a pontosság 0 vagy nincs megadva, akkor csak a nullkarakter jelenti a karak- 
terlánc kiírásának végét. 

b A paraméter egy mutató. A megjelenítéshez használt formátum a megvalósí- 
tástól függ. 

u Előjel nélküli egész paramétert alakít tízes számrendszerbeli alakra. 

n A printfO, az fprintfO vagy az sprintfO meghívásával eddig kiírt karakterek 
számát a mutatott int-be írja. 


Az nem fordulhat elő, hogy nulla vagy kicsi mezőszélesség miatt csonkolás történjen, mert 
a rendszer csak akkor foglalkozik a szélesség kezelésével, ha a mező szélessége meghalad- 


ja a benne szereplő érték szélességét. 


Íme egy kicsivel bonyolultabb példa: 


char" line format - "$sor száma 906d V9OSVNN"; 
int line — 13; 
char" file name -— "Ca4/main.c"; 


brintfCint am); 
brintflline format line file name); 
brintfCint bNn); 


Az eredmény a következő lesz: 


int a; 
ásor száma 13 "C1s-1/main.c" 
int b; 


A printfO függvény használata nem biztonságos, mert a paraméterek beolvasásakor nem 
történik típusellenőrzés. Az alábbi hiba például általában megjósolhatatlan kimenetet ered- 
ményez vagy még nagyobb hibát: 


char x; 
748 
brintf(rossz bemeneti karakter: 90s",Xx); // 90s helyett 90c kell 


A printfO ennek ellenére nagyfokú rugalmasságot biztosít, olyan formában, amelyet a C 
programozók már jól ismernek. 
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A getcharO függvény hasonlóan jól ismert módszert ad karakterek beolvasására: 


int í; 
while ((i-getcharO)!1-EOP) f /? i használata "/ ) 


Figyeljünk rá, hogy a fájlvége jelet csak akkor tudjuk felismerni az int típusú EOF konstans 


segítségével, ha a getcharÓ által visszaadott értéket is int típusú változóban tároljuk és nem 
char típusú adatként. 


A C bemeneti/kimeneti rendszerének alaposabb megismeréséhez olvassunk el egy C kézi- 
könyvet vagy Kernighan és Ritchie A C programozási nyelv című könyvét (Műszaki Könyv- 
kiadó, 1994) IKernighan, 19881]. 


21.9. Tanácsok 


[1] 


[2] 


[3] 


[4] 


[5] 


[6] 


[7] 


[8] 


[91 
[10] 


[11] 


Az olyan felhasználói típusokhoz, melyekhez értelmes szöveges forma rendelhető, 
érdemes megadnunk a :: és a cc operátort. §21.2.3, §21.3.5. 

Ha alacsony precedenciájú operátorokat tartalmazó kifejezések eredményét akarjuk 
megjeleníteni, zárójeleket kell használnunk. §21.2. 

Új 55 és cc operátorok létrehozásához nem kell módosítanunk az istream és az 
ostream osztályt. §21.2.3. 

Olyan függvényeket is készíthetünk, amelyek a második (vagy az utáni) paraméter 
alapján virtuálisként működnek. §21.2.3.1. 

Ne feledjük, hogy a 5: alapértelmezés szerint átugorja az üreshely karaktereket. 
421.3.2. 

Alacsonyszintű bemeneti függvényeket (például get és readO) általában csak ma- 
gasabb szintű eljárások megvalósításához kell használnunk. §21.3.4. 

Mindig körültekintően fogalmazzuk meg a befejezési feltételt, ha a getO, a getlineO 
vagy a readÓ függvényt használjuk. 421.3.4. 

Az állapotjelző bitek közvetlen átállítása helyett használjunk módosítókat 
(manipulator) az [/O vezérléséhez. §21.3.3, §21.4, §21.4.6. 

Kivételeket csak a ritkán előforduló [I/O hibák kezelésére használjunk. §21.3.6. 

A lekötött adatfolyamok az interaktív (felhasználói közreműködést váró) ki- és 
bemenethez nyújtanak segítséget. §21.3.7. 

Ha több függvény be- és kilépési műveleteit egy helyen akarjuk megfogalmazni, 
használjunk őrszemeket. §21.3.8. 
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[12] Paraméter nélküli módosító után ne tegyünk zárójeleket. §21.4.6.2. 

[13] Ha szabványos módosítókat használunk, ne felejtsük ki programunkból az 
iinclude Ciomanip: sort. §21.4.6.2. 

[14] Egy egyszerű függvényobjektum létrehozásával akár egy háromparaméterű operá- 
tor hatását (és hatékonyságát) is megvalósíthatjuk. §21.4.6.3. 

[15] A width meghatározások csak a következő I/O műveletre vonatkoznak. §21.4.4. 

[16] A precision beállításai minden későbbi lebegőpontos kimeneti műveletre hatással 
vannak. §21.4.3. 

[171 A memóriában való formázáshoz használjunk karakterlánc-folyamokat. §21.5.3. 

[18] A fájlfolyamok kezelési módját meghatározhatjuk. §21.5.1. 

[19] Az [/O rendszer bővítésekor különítsük el a formázást (iostream) és az átmeneti tá- 
rolást (streambuj. §21.1, §21.6. 

[20] Az értékek nem szabványos továbbítását átmeneti tárral oldjuk meg. §21.6.4. 

[21] Az értékek nem szabványos formázását adatfolyam-műveletekkel oldjuk meg. 
421.2.3, §21.3.5. 

[22] A felhasználói kódrészleteket elkülöníthetjük és önálló egységként kezelhetjük, ha 
függvénypárokat használunk. §421.6.4. 

[23] Az in avail0 függvény segítségével megállapíthatjuk, hogy a következő bemeneti 
műveletnek várakoznia kell-e majd a bemenetre. §21.6.4. 

[24] Válasszuk szét a biztonsági kérdésekkel foglalkozó eljárásokat azon egyszerű mű- 
veletektől, melyek legfontosabb tulajdonsága a hatékonyság. (Az előbbieket 
a virtual, az utóbbiakat az inline kulcsszóval adjuk meg.) §21.6.4. 

[25] Használjuk a locale osztályt a , kulturális különbségek" megfogalmazására. §421.7. 

[26] A sync with stdioCx) függvénnyel a C stílusú ki- és bemenetet összeegyeztethetjük 
a Cst [/O rendszerével, de teljesen szét is választhatjuk azokat. §21.8. 

[27] A C stílusú [/O használatakor mindig nagyon figyeljünk a típushibák elkerülésére. 
421.8. 


21.10. Feladatok 


1. C1.5) Olvassunk be egy lebegőpontos számokat tartalmazó fájlt, a beolvasott 
számpárokból készítsünk komplex értékeket, majd ezeket írjuk ki. 

2. C1.5) Határozzuk meg a Name and address (Név és cím) típust. Adjuk meg hozzá 
a C£ és a 55 operátort. Másoljunk le egy Name and address objektumokat tartal- 
mazó adatfolyamot. 

3. (2.5) Próbáljunk meg lemásolni olyan Name and address objektumokból álló 
adatfolyamot, melyben a lehető legtöbb hiba szerepel (például formázási hibák, 
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karakterláncok túl korai végződése stb.). Próbáljuk meg úgy kezelni ezeket a hibá- 
kat, hogy a másoló függvény a helyesen formázott Name and address objektumok 
többségét be tudja olvasni még akkor is, ha a bemenet korábban teljesen összeke- 
veredett. 

4. (2.5) Írjuk újra a Name and address típus kimeneti formáját úgy, hogy az kevés- 
bé legyen érzékeny a formázási hibákra. 

5. (2.5) Készítsünk néhány függvényt különböző típusú információk bekéréséhez 
és beolvasásához (például egészekhez, lebegőpontos számokhoz, fájlnevekhez, 
e-mail címekhez, dátumokhoz, személyi adatokhoz stb.). Próbáljunk minél üzem- 
biztosabb függvényeket készíteni. 

6. (1.5) írjunk programot, amely kiírja (a) az összes kisbetűt, (b) az összes betűt, (c) 
az összes betűt és számjegyet, (d) minden karaktert, amely rendszerünkben C-t 
azonosítóban szerepelhet, (e) az összes írásjelet, (D a vezérlőkarakterek kódjait, (g) 
az összes üreshely karaktert, (h) az üreshely karakterek kódjait, és végül (i) minden 
látható karaktert. 

7. 2) Olvassunk be szövegsorokat egy rögzített méretű karakteres átmeneti tárba. 
Töröljünk minden üreshely karaktert és az alfanumerikus karaktereket helyettesít- 
sük az ábécé következő karakterével (a z betűt a-ra, a 9-et 0-ra cseréljük). Írjuk ki 
az így keletkező sorokat. 

8. C3) Készítsünk egy miniatűr adatfolyam [/O rendszert, melyben definiáljuk az 
istream, az ostream, az ifstream, és az ofstream osztályt, melyek biztosítják az 
operators ( ) és az operator:?( ) függvényt egész értékekhez, illetve az olyan eljá- 
rásokat, mint az openO és a closeO a fájlok kezeléséhez. 

9. C4) Írjuk meg a C szabványos ki- és bemeneti könyvtárát (csidio.h:) a C- szab- 
ványos [/O könyvtárának (ciostream?) felhasználásával. 

10.C4) Írjuk meg a Cs szabványos [/O könyvtárát (ciostream?) a C szabványos [/D 
könyvtárának (cstdio.h:) felhasználásával. 

11.C4) Írjuk meg a C és a Cst könyvtárat úgy, hogy azokat egyszerre használhassuk. 

12. (2) Készítsünk egy osztályt, amelyben a / / operátor segítségével közvetlenül ol- 
vashatjuk be egy fájl karaktereit. 

13.C3) Ismételjük meg a §21.10[12] feladatot úgy, hogy a / / operátort írásra és olvasás- 
ra is használhassuk. Ötlet: a / Jadjon vissza egy olyan objektumot, amely egy fájl- 
pozíciót azonosít. Az ezen objektumra vonatkozó értékadás írja a fájlba a megfelelő 
adatokat, míg az objektumnak cAar típusra való automatikus konverziója jelentse 
a megfelelő karakter beolvasását az állományból. 

14. (2) Ismételjük meg a §21.10[13] feladatot úgy, hogy a / / operátor tetszőleges típu- 
sú objektum beolvasásához használható legyen, ne csak karakterekhez. 

15.(C3.5) írjuk meg az istream és az ostream olyan változatát, amely a számokat biná- 
ris formában írja ki, és olvassa be ahelyett, hogy szöveges alakra alakítaná azokat. 
Vizsgáljuk meg ezen megközelítés előnyeit és hátrányait a karakteralapú megköze- 
lítéssel szemben. 


21. Adatfolyamok 883 


16. C3.5) Tervezzünk és írjunk meg egy mintaillesztő bemeneti műveletet. Használ- 
junk printf stílusú formázott karakterláncokat a minta meghatározásához. Azt is te- 
gyük lehetővé, hogy többféle mintát , rápróbálhassunk" a bemenetre a formátum 
megtalálásához. A mintaillesztő bemeneti osztályt származtassuk az istream osz- 
tályból. 

17.04) Találjunk ki (és írjunk meg) egy sokkal jobb mintaillesztési eljárást. Határoz- 
zuk meg pontosan, miben jobb a mi megoldásunk. 

18. (2) Határozzunk meg egy kimeneti módosítót (neve legyen based), amely két pa- 
ramétert kap: egy alapszámot és egy int értéket, és az egésznek az alapszám sze- 
rinti számrendszerbeli alakját írja a kimenetre. A based(2, 9) hatására például az 
1001 jelenjen meg a kimeneten. 

19. €"2) Készítsünk módosítókat, melyek ki- és bekapcsolják a karakterek visszaírását 
(echoing). 

20.(2) Írjuk meg a §21.4.6.3 rész Bound form osztályát a szokásos beépített típusok- 
ra. 

21. (2) Írjuk meg a §21.4.6.3 rész Bound form osztályát úgy, hogy egy kimeneti mű- 
velet soha ne csordulhasson túl a számára megadott widthO értéken. Azt is biztosí- 
tanunk kell a programozó számára, hogy a kimenet soha ne csonkuljon a megadott 
pontossági érték miatt. 

22.03) Készítsünk egy encrypt(k) módosítót, melynek hatására az ostream objektu- 
mon minden kimenet a k értékkel titkosítva jelenik meg. Írjuk meg a módosító 
decrypt(k) párját is az istream osztályra. Adjunk lehetőséget a titkosítás kikapcsolá- 
sára is, tehát tudjunk újra , olvasható" szöveget írni a kimenetre. 

23.(€"2) Kövessük végig egy karakter útját rendszerünkben a billentyűzettől a képer- 
nyőig az alábbi egyszerű utasítássorozat esetében: 


char c; 
cin 55 c; 
cout ££ c cz endl; 


24. 2) Módosítsuk a §21.3.6 pont readintsO függvényét úgy, hogy minden kivételt 
kezelni tudjon. Ötlet: ,kezdeti értékadás az erőforrás megszerzésével". 

25. (2.5) Minden rendszerben lehetőség van arra, hogy dátumokat írjunk, olvassunk 
és ábrázoljunk egy locale objektum leírása szerint. Találjuk meg saját rendszerünk 
dokumentációjában, hogyan valósíthatjuk ezt meg, és készítsünk egy rövid progra- 
mot, amely e módszer felhasználásával ír és olvas karaktereket. Ötlet: struct tm. 

26. 2.5) Hozzuk létre az ostrstream osztályt az ostream osztályból való származtatás- 
sal úgy, hogy egy karaktertömbhöz (C stílusú karakterlánchoz) köthessük hozzá, 
ugyanúgy, ahogy az ostringstream köthető egy szring objektumhoz. Ne másoljuk 
be a tömböt az ostrstream objektumba, sem ki onnan. Az ostrstream osztálynak 
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egyszerű lehetőséget kell adnia a tömbbe való írásra. Az osztályt olyan memóriá- 
ban végzett formázásokra szeretnénk felhasználni, mint az alábbi: 


char bujlmessage sizel; 

ostrstream ost(buf,;message size); 

do something(arguments, ost); // kiírás buf-ra ost-on keresztül 
cout ££ buf; // ost hozzáadja a lezáró 0-t 


A do somethingO-hoz hasonló műveletek az ost adatfolyamra írnak, esetleg to- 
vábbadják azt saját rész-műveleteiknek, és a szabványos kimeneti függvényeket 
használják. A túlcsordulás ellenőrzésére nincs szükség, mert az ost ismeri a saját 
méretét és failO állapotba kerül, amikor megtelik. Végül a disblayO művelet meg- 
hívásával az üzenetet egy , valódi" kimeneti adatfolyamba írhatjuk. Ez a módszer 
nagyon hasznos lehet akkor, ha a végső kimeneti eszköz bonyolultabban tudja 
megvalósítani a kimenetet, mint a szokásos sorkiíráson alapuló kimeneti eszközök. 
Az ost objektumban tárolt szöveget például megjeleníthetjük a képernyő egy rögzí- 
tett méretű területén. Ugyanígy hozzuk létre az istrstream osztályt, amely egy be- 
meneti karakterlánc-folyam, ami nullkarakterrel lezárt karakterláncból olvas. A le- 
záró nullkaraktert használjuk fájlvége jelként. Ezek az strstream osztályok az erede- 
ti adatfolyam-könyvtár részét képezték és gyakran szerepelnek a cstrstream.h?: fej- 
állományban. 

27.C2.5) Készítsük el a general0 módosítót, amely visszaállítja az adatfolyamot az 
eredeti formátumára, hasonlóan ahhoz, ahogy a scientificO (§21.4.6.2) az adatfolya- 
mot tudományos formátumra állítja. 


kf 


Számok 


, A számítás célja nem a szám, 
hanem a tisztánlátás." 
(R.W. Hamming) 


,,... de a tanulónak gyakran 
számokon keresztül 

vezet az út a tisztánlátáshoz." 
(A. Ralston) 


Bevezetés e A számtípusok korlátai s Matematikai függvények e valarray s Vektorműve- 
letek e Szeletek e s/lice array s Az ideiglenes változók kiküszöbölése e gslice array 
e mask array s indirect array s complex s Általánosított algoritmusok s Véletlen számok 
e Tanácsok e Gyakorlatok 
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22.1. Bevezetés 


A gyakorlatban ritkán akadunk olyan programozási feladatra, ahol nincs szükség valami- 
lyen számokkal végzett műveletre. Programjainkban általában -— az alapvető aritmetikai mű- 
veleteken kívül — szükségünk van egy kis igazi matematikára is. Ez a fejezet a standard 
könyvtár ehhez kapcsolódó szolgáltatásait mutatja be. 


Sem a C, sem a C4- nyelvet nem elsődlegesen számműveletek elvégzésére tervezték. Azok 
viszont jellemzően más környezetbe beágyazva fordulnak elő — megemlíthető itt az adatbá- 
Zis- illetve hálózatkezelés, a műszerek vezérlése, a grafika, a pénzügyi számítások, valamint 
a szimuláció különböző területei —, így a Ct4 remek lehetőségeket nyújthat a némileg bo- 
nyolultabb matematikai feladatok elvégzésére is, amelyekkel az előbb említett területek 
megfelelően kiszolgálhatók. A számműveletek skálája igen széles, az egyszerű ciklusoktól 
a lebegőpontos számokból alkotott vektorokig terjed. A C-4- ereje az ilyen összetettebb 
adatszerkezeteken végzett műveleteknél mutatkozik meg igazán, ezért egyre gyakrabban 
alkalmazzák mérnöki és tudományos számítások elvégzésére. A fejezetben a standard 
könyvtár azon szolgáltatásaival és eljárásaival ismerkedhetünk meg, melyek kifejezetten 
a számműveletek elvégzését támogatják a C-t környezetben. A matematikai alapok tisztá- 
zására kísérletet sem teszünk, ezeket ismertnek tételezzük fel. Az esetleges hiányosságok 
matematikai (és nem számítástechnikával foglalkozó) szakkönyvekből pótolhatók. 


22.2. A számtípusok korlátozásai 


Ha egy programban nem csupán alapszinten végzünk számműveleteket, mindenképpen 
szükség van arra, hogy ismerjük a beépített típusok alapvető tulajdonságait. Ezek sokkal in- 
kább az adott fejlesztőkörnyezettől függnek, mintsem a nyelv szabályaitól (§4.6). Például 
melyik a legnagyobb ábrázolható inf? Mekkora a legkisebb /loaf Mi történik egy double tí- 
pusú számmal, ha floattípusúvá alakítjuk? Kerekíti vagy csonkítja a rendszer? Hány bitet tar- 
talmaz a char típus? 


Az ilyen, és ehhez hasonló kérdésekre a climitsz fejállományban leírt numeric limits sab- 
lon (template) specializációi szolgálhatnak válasszal. Lássunk egy példát: 
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void (double d, int i) 
f 
if (numeric limitszunsigned char?:::digits !- 8) ( 
// szokatlan bájt (a bitek száma nem 8) 


) 


if (IScnumeric limitszshort:::minO 11] numeric limitszshort:::maxOci) f 
// i nem tárolható short típusban értékvesztés nélkül 


) 
if (Oxd kk dénumeric limitszdoublez::epsilonO) d — 0; 


if (numeric limitscOuad:::is specialized) f 
// a Ouad típushoz rendelkezésre állnak korlát-adatok 
) 
J 


Minden specializáció biztosítja a saját paramétertípusának legfontosabb információkat. Kö- 
vetkezésképpen az általános numeric limits sablon egyszerűen arra szolgál, hogy szabvá- 
nyos nevet adjon néhány konstansnak és helyben kifejtett (inline) függvénynek: 


templatexclass T: class numeric limits f 
bublic: 
static const bool is specialized - false; // Ál rendelkezésre információ 
// a numeric limitszT5-ről? 


// érdektelen alapértelmezések 


VA 


A tényleges információ az egyedi célú változatokban (specializációkban) szerepel. A stan- 
dard könyvtár minden változata az összes alaptípushoz (karakterekhez, egészekhez, valós 
számokhoz, valamint a logikai típushoz) szolgáltat egy-egy specializációt a numeric limits- 
ből. Nem szerepel viszont ilyen a többi típushoz: a void mutatóhoz, a felsoroló típusokhoz, 
vagy a könyvtári típusokhoz (például a complexzdouble: szerkezethez). 


A beépített típusok (például a char) esetében csupán néhány adat említésre méltó. Lássunk 
egy numeric limitszchar:-t olyan megvalósításban, ahol a cAhuar 8 bites és előjeles: 


class numeric limitszchar? ( 
bublic: 


static const bool is specialized — true; // igen, van adat 


static const int digits — 7; // bitek száma ("bináris számjegyek") előjel nélkül 
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static const bool is signed - true; // ebben a megvalósításban a char típus 
// előjeles (signed) 
static const bool is integer — true; // a char egész jellegű típus 


static char minŐ throug f return -128; ? // legkisebb érték 
static char maxO throu0 f return 127; ) // legnagyobb érték 


// deklarációk, amelyek közömbösek a char típus számára 


Jegyezzük meg, hogy egy előjeles egész típus ténylegesen számábrázolásra használt bitjei- 
nek száma (digits) eggyel kevesebb a típushoz rendelt bitszámnál, hiszen egy bitet az elő- 
jel foglal le. 


A numeric limits tagjainak többsége a lebegőpontos számok leírására szolgál. A követke- 
ző példa egy lehetséges //oat-változatot mutat: 


class numeric limitszfloat: f 
bublic: 
static const bool is specialized — true; 


static const int radix — 2; // a kitevő típusa (ebben az esetben 2-es alapú) 
static const int digits - 24; // radix számjegyek a mantisszában 
static const int digits10 — 6; // 10-es alabú számjegyek a mantisszában 


static const bool is signed - true; 
static const bool is integer — false; 
static const bool is exact -— false; 


static float minŐ throu0 f return 1.17549435E-38K,; ) 
static float maxO throu0O f return 3.40282347E3386k,; ) 


static float epsilonÖ throuO f return 1.19209290£E-O7E; ) 
static float round errorO throug f return 0.5F; ) 


static float infinityO throu0O f return / valamilyen érték "/; ) 

static float guiet NaNO throwu0 f return /? valamilyen érték "/; ) 
static float signaling NaNO throu0O f return /? valamilyen érték "/; ) 
static float denorm minO througO f return minO; ) 


static const int min exbonent — -125; 
static const int min exbonent10 — -37; 
static const int max exponent — 4128; 
static const int max exponent10 — 438; 
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static const bool has infinity — true; 

static const bool has guiet NaN - true; 

static const bool has signaling NaN - true; 

static const float denorm style has denorm - denorm absent; // enum a Zlimitsz-ből 
static const bool has denorm loss — false; 





static const bool is iec559-true; — // megfelel IEC-559-nek 
static const bool is bounded — true; 

static const bool is modulo - false; 

static const bool traps — true; 

static const bool tinyness before — true; 


static const float round style round style - round to nearest; // enum a zlimitsz-ből 


); 


Ne feledjük, hogy a minO a legkisebb pozitív normált szám, az epsilon pedig a legkisebb 
pozitív lebegőpontos szám, amelyre az 1-epsilon-1 ábrázolható. 


Amikor egy skalár típust egy beépített típus segítségével definiálunk, érdemes egyúttal 
a numeric limits megfelelő specializációját is megadnunk. Ha például egy négyszeres pon- 
tosságú Ouad, vagy egy különlegesen pontos egész, long long típust készítünk, a felhasz- 
nálók jogos elvárása, hogy létezzenek a numeric limitszOuad: és a numeric limitszlong 
long: specializációk. 


A numeric limits-nek elképzelhető olyan változata, mely egy olyan felhasználói típus tulaj- 
donságait írja le, melynek nem sok köze van lebegőpontos számokhoz. Az ilyen esetekben 
rendszerint ajánlatosabb a típustulajdonságok leírására használt általános eljárás alkalmazá- 
sa, mint egy új numeric limits meghatározása olyan tulajdonságokkal, melyek a szabvány- 
ban nem szerepelnek. 


A lebegőpontos számokat helyben kifejtett (inline) függvények ábrázolják. A numeric limits 
osztályban szereplő egész értékeket viszont olyan formában kell ábrázolnunk, amely meg- 
engedi, hogy konstans kifejezésekben felhasználjuk azokat, ezért ezek az elemek osztályon 
belüli kezdeti értékadással rendelkeznek (§10.4.6.2). Ha ilyen célokra static const tagokat 
használunk felsoroló típusok helyett, ne felejtsük el definiálni a szatic elemeket. 
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22.2.1. Korlátozási makrók 


A C44 örökölte a C-től azokat a makrókat, melyek leírják az egész típusok tulajdonságait. 
Ezek a cclimits2, illetve a climits.h: fejállományban szerepelnek. Ilyen makró például 
a CHAR BIT vagy az INT MAX. Ugyanígy a ccfloat: és a Sloat.h: fejállomány azokat 
a makrókat tartalmazza, amelyek a lebegőpontos számok tulajdonságait írják le. Ezekre pél- 
da a DBL MIN. EXP, a FLT RADIX vagy a LDBL MAX. 


Mint mindig, a makrókat most is érdemes elkerülnünk. 


22.3. Szabványos matematikai függvények 


A ccmath: és a cmath.h? fejállomány szolgáltatja azokat a függvényeket, amelyeket álta- 
lában , szokásos matematikai függvényeknek" nevezünk: 


double abs(double); // abszolúűtérték, ugyanaz mint fabsO; ilyen nincs a C-ben 
double fabs(double); // abszolűtérték 
double ceil(double d); // a d-nél nem kisebb legkisebb egész 
double floor(double 4); // a d-nél nem nagyobb legnagyobb egész 
double sgrt(double d); // d négyzetgyöke, d nem negatív kell legyen 
double pou(double d, double e); // d e-edik hatványa, 
// hiba, ha d--0 és ec-0, vagy ha d20 és e nem egész 
double pouw(double d, int i); // d i-edik hatványa; ilyen nincs a C-ben 
double cos(double); // koszinusz 
double sin(double); // szinusz 
double tan(double); // tangens 
double acos(double); // arkusz koszinusz 
double asin(double9; // arkusz szinusz 
double atan(double); // arkusz tangens 
double atan2(double x, double y); // atan(x/y) 
double sinh(double); // szinusz hiperbolikusz 
double cosh(double); // koszinusz hiperbolikusz 


double tanh(double); // tangens hiperbolikusz 
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double exp(double); // e alapú exponenciális 

double log(double 4); // természetes (e alapú) logaritmus, 
// d nagyobb kell legyen 0-nál 

double log10(double d); // 10-es alapú logaritmus, d nagyobb kell legyen 0-nál 


double mod((double d, double? p); // d tört részével tér vissza, 
// az egész részt "p-be helyezi 
double frexp(double d, int" p); // x eleme [.5,1) és y úgy, hogy d - x"bow(2,y) legyen; 
// visszatérő érték x, y "p-be helyezése 
double fmod(double d, double m); // lebegőpontos maradék, előjele megfelel d előjelének 
double idexp(double d, int i); /[// ddcbpow(2,) 


A ccmath: és a cmath.h? fejállomány ugyanezeket a függvényeket float és long double pa- 
raméterekkel is elérhetővé teszi. 


Ha egy műveletnek több lehetséges eredménye is van (mint például az asinO esetében), 
a függvények a nullához legközelebbi értéket adják vissza. Az acosO0 eredménye mindig 
nemnegatív. 


Ezek a függvények a hibákat az Cerrno: fejállományban szereplő errno változó beállításá- 
val jelzik. Ennek értéke EDOM, ha egy függvény nem értelmezhető a megadott paraméter- 
re, és ERANGE ha az eredmény nem ábrázolható az adott típussal: 


void JO 
( 
errno — 0; // törli az előző hibakódot 
sgrt(-1U; 
if (errno--—EDOM) cerr cz "A sgrtÖ nem definiált negatív paraméter esetén"; 
bou(numeric limitszdoublez::maxO, 29; 
if (errno -—- ERANGE) cerr ££ "A powO eredménye túl nagy ahhoz," 
za "hogy double-ként ábrázoljuk"; 


A C44 előzményeire visszavezethető okokból néhány matematikai függvény a ccsidlib: fej- 
állományban szerepel a ccmath: helyett: 


int abs(int9; // abszolútérték 
long abs(long); // abszolútérték ; ilyen nincs a C-ben 
long labs(long); // abszolútérték 


struct div tf megvalósítás függő guot, rem; ); 
struct Idiv tf megvalósítás függő guyot, rem; ? ; 
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div t div(Cint n, int d); // n osztása d-vel, visszatérés (kvőciens, maradék) 

ldiv t div(long int n, long int d); // n osztása d-vel, visszatérés (kvóciens, maradék); 
// ilyen nincs a C-ben 

Idiv t Idiv(long int n, long int d); // n osztása d-vel, visszatérés (kvóciens, maradék) 


22.4. Vektorműveletek 


A legtöbb számítási feladat viszonylag egyszerű, egydimenziós vektorokra vonatkozik, 
amelyek lebegőpontos számokat tárolnak. Ezért a nagyteljesítményű számítógépek külön 
támogatják az ilyen vektorok kezelését, a velük foglalkozó könyvtárak széles körben hasz- 
nálatosak, és nagyon sok területen létfontosságú az ilyen vektorokat kezelő függvények le- 
hető legoptimálisabb kialakítása. A standard könyvtár tartalmaz egy olyan vektort 
(valarray), amelyet kifejezetten a szokásos matematikai vektorműveletek gyors végrehajtá- 
sára dolgoztak ki. 


Miközben áttekintjük a valarray lehetőségeit, mindig gondoljunk arra, hogy ez egy vi- 
szonylag alacsony szintű programelem, amely nagy hatékonyságú számítások elvégzéséhez 
készült. Tehát az osztály tervezésekor a legfontosabb célkitűzés nem a kényelmes haszná- 
lat volt, hanem a nagyteljesítményű számítógépek lehetőségeinek minél jobb kihasználása, 
a legerősebb optimalizálási módszerek alkalmazása. Ha saját programunkban a rugalmas- 
ság és az általánosság fontosabb, mint a hatékonyság, valószínűleg érdemesebb a szabvá- 
nyos tárolók közül választanunk (melyeket a 16. és a 17. fejezet mutat be), ne is próbáljunk 
a valarray egyszerű, hatékony és szándékosan hagyományos kereteihez igazodni. 


Felmerülhet bennünk a kérdés, hogy miért nem a valarray neve lett vector, hiszen ez a ha- 
gyományos, matematikai vektor valódi megfelelője, és a §16.3 pont vector osztályát kéne in- 
kább array típusnak nevezni. A terminológia mégsem ezt az elnevezési rendet követi. 
A valarray numerikus számításokra optimalizált vektor, míg a vector egy rugalmas tároló, 
amely a legkülönbözőbb típusú objektumok tárolására és kezelésére szolgál. Az , array" 
(tömb) fogalma erősen kötődik a beépített tömbtípushoz. 


A valarray típust négy kisegítő típus egészíti ki, melyek a valarray egy-egy részhalmazát 
képezik: 


6 Aslice array és a gslice array a szeletek Cslice) fogalmát ábrázolják (422.4.6, 
422.4.8). 

6 A mask array egy részhalmazt határoz meg, úgy, hogy minden elemről meg- 
mondja, hogy az benne van-e a részhalmazban vagy sem (422.4.9). 
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6 Az indirect array a részhalmazba tartozó elemek indexértékeinek (sorszámai- 
nak) listáját tartalmazza (422.4.10). 
22.4.1. Valarray létrehozása 


A valarray típus és a hozzá tartozó szolgáltatások definiciója az std névtérben szerepel és 
a cvalarray? fejállomány segítségével érhető el: 


templatexciass T- class std::valarray f 


// ábrázolás 

bublic: 
typedef T value type; 
valarrayO; // valarray size0--0 mérettel 
explicit valarray(size t n); // n elem, értékük: TO 
valarray(const Tg val, size tn); // n elem, értékük: val 
valarray(const T" p, size tn); // n elem, értékük: pfl0], pl1], ... 
valarray(const valarray8£ vV); // v másolata 
valarray (const slice arraysT2£); // lásd §22.4.6 
valarray (const gslice arrayST-£ ); // lásd §22.4.8 
valarray(const mask arraysT:2£ ); // lásd §22.4.9 
valarray (const indirect arrayST2£); // lásd 622.4.10 
-valarrayO; 
Mant 


a 


Ezek a konstruktorok lehetővé teszik, hogy egy valarray objektumnak a kisegítő numeri- 


kus tömbtípusok vagy önálló értékek segítségével adjunk kezdőértéket: 


valarrayZdouble: vo; // helyfoglalás, vO-nak később adunk értéket 
valarraysfloat: v1(1000); // 1000 elem, mindegyik értéke float0--0O.OF 
valarraysint2 v2(-1,2000); // 2000 elem, mindegyik értéke -1 


valarraysdouble: v3(100,9.8064);  // hiba: lebegőpontos valarray méret 


valarrayZdouble: vá - v3; // vá elemszáma v3.sizeO 


A kétparaméterű konstruktorokban az értéket az elemszám előtt kell megadnunk. Ez eltér 
a szabványos tárolókban használt megoldástól (§16.3.4. 
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A másoló konstruktornak átadott valarray paraméter elemeinek száma határozza meg a lét- 
rejövő valarray méretét. 


A legtöbb program táblákból vagy valamilyen bemeneti művelet segítségével jut hozzá az ada- 
tokhoz. Ezt támogatja az a konstruktor, amely egy beépített tömbből másolja ki az elemeket: 


const double vd[ ] - ( O, 1, 2, 3, 4); 
constintvi[]-( O, 1, 2, 3, 43; 


valarrayZdouble: v3(vd,49; // 4 elem: 0,1,2,3 
valarrayZdouble: vá(vi 4);  // típushiba: vi nem double-ra mutat 
valarrayZdouble: v5(vd,8); // nem meghatározott: tűl kevés elem a kezdőérték-adóban 


Ez a kezdőérték-adó forma nagyon fontos, mert a legtöbb numerikus program nagy töm- 
bök formájában adja meg az adatokat. 


A valarray típust és kisegítő szolgáltatásait nagy sebességű számításokhoz tervezték. Ez né- 
hány, a felhasználókra vonatkozó korlátozásban, és néhány, a megvalósítókra vonatkozó 
engedményben nyilvánul meg. A valarray készítője szinte bármilyen optimalizálási mód- 
szert használhat, amit csak el tud képzelni. A műveletek például lehetnek helyben kifejtet- 
tek, a valarray műveleteit pedig mellékhatások nélkülinek tekinthetjük (persze saját para- 
métereikre ez nem vonatkozik). Egy valarray objektumról feltételezhetjük, hogy nem 
rendelkezik álnévvel (alias), kisegítő típusokat bármikor bevezethetünk, és az ideiglenes 
változókat is szabadon kiküszöbölhetjük, ha az alapvető jelentést így is meg tudjuk tartani. 
Ezért a cvalarray? fejállományban szereplő deklarációk jelentősen el is térhetnek az itt be- 
mutatott (és a szabványban szereplő) formától, de azon programok számára, melyek nem 
sértik meg a szabályokat, mindenképpen ugyanazokat a műveleteket kell biztosítaniuk, 
ugyanazzal a jelentéssel. A valarray elemeinek másolása például a szokásos módon kell, 
hogy működjön (417.1.4. 


22.4.2. A valarray indexelése és az értékadás 


A valarray osztály esetében az indexelés egyaránt használható önálló elemek eléréséhez és 
résztömbök kijelöléséhez: 


templatexcilass T- class valarray f 
bublic: 
Ma 
valarray£ operator-(const valarrayét V); // v másolása 
valarray£k operator—(const Ik val); // minden elem val-t kapja értékül 
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T operatorl (size D const; 
I£ operatorf [(size D; 


valarray operator [(slice) const; // lásd §22.4.6 
slice array£T: operatorf I(slice); 


valarray operatorl[ [(const gslicek ) const; // lásd §22.4.8 
gslice arraycT: operatori [(const gsliceg ); 


valarray operatori K(const valarraycbool:£ ) const; // lásd §22.4.9 
mask arrayzT- operatorl (const valarraycbool:£ ); 


valarray operatorl [(const valarraycssize tk) const; — // lásd 622.4.10 
indirect array£I: operatorl Kconst valarraycsize t2£); 


valarrayk operator—(const slice arraycT-£); // lásd §22.4.6 
valarrayk operator—(const gslice arraycT:£ ); // lásd §22.4.8 
valarrayk operator—(const mask arraysT-£); // lásd §22.4.9 
valarrayk operator—(const indirect arrayST-£ ); // lásd §22.4.10 
VE 


VA 


Egy valarray objektumot értékül adhatunk egy másik, ugyanolyan méretű valarray-nek. 
Elvárásainknak megfelelően a vJ-v2 utasítás a v2 minden elemét a v7 megfelelő elemébe 
másolja. Ha a tömbök különböző méretűek, az eredmény nem meghatározott lesz, mert 
a sebességre optimalizált valarray osztálytól nem követelhetjük meg, hogy nem megfelelő 
méretű objektum értékül adásakor könnyen érthető hibajelzést (például kivétel) kapjunk, 
vagy más, logikus viselkedést tapasztaljunk. 


Ezen hagyományos értékadás mellett lehetőség van arra is, hogy egy valarray objektumhoz 
egy skalár értéket rendeljünk. A v-7 utasítás például a v valarray minden egyes elemébe 
a 7 értéket írja. Ez első ránézésre elég meglepő, és szerepét úgy érthetjük meg leginkább, 
ha úgy gondolunk rá, mint az értékadó műveleteknek egy, néhány esetben hasznos, , elfaj- 
zott" változatára (422.4.3). 


Az egészekkel való sorszámozás a szokásos módon működik, tartományellenőrzés nélkül. 


Az önálló elemek kiválasztása mellett a valarray indexelése lehetőséget ad résztömbök 
négyféle kijelölésére is (§22.4.609. Megfordítva, az értékadó utasítások (és a konstruktorok, 
422.4.1) ilyen résztömböket is elfogadnak paraméterként. A valarray típusra megvalósított 
értékadó utasítások biztosítják, hogy a kisegítő tömb típusokat (mint a slice array) ne kell- 
jen átalakítanunk valarray típusra, mielőtt értékül adjuk azokat. A hatékonyság biztosítása 
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érdekében egy alapos fejlesztőkörnyezetnek illik a vektor más műveleteihez (például a 4 
és a ") is biztosítani az ilyen változatokat. Ezenkívül a vektorműveletek számtalan módon 
optimalizálhatók, szeletek (slice) vagy más kisegítő vektortípusok használatával. 

22.4.3. Műveletek tagfüggvényként 

A nyilvánvaló és a kevésbé nyilvánvaló tagfüggvények listája következő: 


templatexcilass T- class valarray f 








bublic: 
K/S 
valarray£k operator"—(const Ik arg); // ulil"-arg minden elemre 
// hasonlóan: /-, 90—-, 4-, -—— M- £-, ]— cc- és 55 
T sumÓ const; // elemek összege, t1- használatával 
T minO const; // legkisebb érték, c használatával 
T max0O const; // legnagyobb érték, c használatával 
valarray shijftGint i) const; // logikai léptetés (balra, ha Oci; jobbra, ha i£0) 
valarray cshift(int i) const; // ciklikus léptetés (balra, ha OKi; jobbra, ha iz0) 
valarray applh(T KD) const; // eredmény[íj - fuli)) minden elemre 


valarray apply(T (const I£)) const; 


valarray operator-) const; // eredmény[íj - -ulil minden elemre 
// hasonlóan: 4, -, ! 


size t size) const; /7/ elemek száma 
void resize(size t n, const Ik val — TO); // n elem, értékük val 


Ha size0-0, akkor sumO, minO és max0O értéke nem meghatározott. 


Például, ha v egy valarray, akkor a vt-.2 vagy a w7-1.3 utasítások alkalmazhatóak rá. Ha 
skalárműveleteket hajtunk végre egy vektoron, akkor az azt jelenti, hogy a vektor minden 
elemére elvégezzük azt. Szokás szerint, egyszerűbb a "- műveletet optimalizálni, mint a " 
és az -— párosítását (411.3.1). 
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Figyeljük meg, hogy a nem értékadó műveletek mindig új valarray objektumot hoznak létre: 


double incr(double d) f return d- 1; ) 


void fvalarrayzdoublex£g v) 
( 


valarrayzdouble: v2 - v.applyGincr); // új, megnövelt valarray-t hoz létre, megnövelt értékkel 


J 


Ezen programrészlet hatására a v értéke nem változik. Sajnos az abplyO nem képes függ- 
vényobjektumokat (418.4) használni paraméterként (422.9.[1D. 


A logikai és a ciklikus léptető függvények (a sAijtO és a cshiftO) olyan új valarray objektu- 
mokat adnak vissza, amelyben az elemek megfelelően el vannak léptetve. Az eredeti vek- 
tor itt is változatlan marad. A v2-v.cshift(n) ciklikus léptetés például egy olyan valarray ob- 
jektumot eredményez, melynek elemeire v2/i/-—u[(i3n)96v.size0].. A v3-v.shift(n) logikai 
léptető művelet hatására a v3/i/ a ulitn] értéket veszi fel, ha az i-tn létező indexe a v vektor- 
nak. Ellenkező esetben az adott elembe a vektor alapértelmezett értéke kerül. Ebből követ- 
kezik, hogy a shijftŐ és a cshiftO is balra tolja az elemeket, ha pozitív paramétert adunk 
meg, és jobbra, ha negatív értéket: 


void JO 

f 
int alpha[l ] - f 1, 2, 3, 4, 5 ,6, 7, 8 ); 
valarraysint- alpha, 89; // 1, 2, 3, 4, 5, 6, 7 § 
valarrayzint: v2 — v.shift2; //3, 4, 5, 6, 78, 0, 0 
valarrayzint? v3 - vcá2; 4, 8, 12, 16, 20, 24, 28, 32 
valarraysint: vá — v.shift(-29; //0,0,1,2 3, 4 5, 6 
valarraysint: v5 -— v352; //O, 0, O, 1, 1, 1, 1, 2 
valarrayzint: v6 — v.cshift(29; // 3, 4, 5, 6, 7, S, 1, 2 
valarrayzint? v7 - v.cshijft(-29; /7 8,1,234.5 6 

j 


A valarray típus esetében a c£ és a 55 operátor bitenkénti léptetést végez, tehát nem ele- 
meket tolnak el és nem is I/O műveletek (422.4). Ennek megfelelően a c£- és a 25- műve- 
letekkel elemeken belüli eltolást végezhetünk egész típusú elemek esetében: 


void fvalarrayzint: vi, valarrayzdouble: vd) 
( 
vi c£- 2 // vilijzs-2, vi minden elemére 
vd ££- 2 // hiba: a léptetés nem meghatározott lebegőpontos értékekre 


J 
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A valarray méretét módosíthatjuk is. A resizeŐ itt nem arra szolgál, hogy a valarray osz- 
tályt egy dinamikusan növekedni képes adatszerkezetté tegye — mint ahogy a vector és 


a string esetében történik —, hanem új kezdőértéket adó művelet, amely a létező elemeket 
is lecseréli a valarray alapértelmezett értékére, így a régi elemeket véglegesen elveszítjük. 


Az átméretezésre szánt valarray objektumokat gyakran üres vektorként hozzuk létre. Gon- 


doljuk végig például, hogyan adhatunk kezdőértéket egy valarray objektumnak bemenet 
alapján: 


void JO 

( 
int n - 0; 
cin 22 n; // a tömb méretének beolvasása 
if (1250) error( "hibás tömbméret"); 


valarraycdoublez 1(m); // tömb létrehozása a szükséges mérettel 
int i — 0; 
while (izn kg cinszzulira)) ; // a tömb feltöltése 


if (i1-n) error( "túl kevés bemeneti elem"); 


Me 


Ha a bemenetet külön függvényben szeretnénk kezelni, a következőt tehetjük: 


void initialize from input(valarrayzdoublezk v) 


( 


intn - 0; 
cin 22 n; // a tömb méretének beolvasása 
if (1250) error( "hibás tömbméret"); 


v.resize(n); // v átméretezése a szükséges méretre 
inti —- 0; 
while (izn kk cinszzulira)) ; // a tömb feltöltése 


if (i1-n) error( "túl kevés bemeneti elem"); 


j 


void g0 

( 
valarrayZdouble: u; // alapértelmezett tömb létrehozása 
initialize from input(v); // v méretezése és feltöltése 
Ms 


j 


Ezzel a megoldással elkerülhetjük nagy méretű adatterületek másolását. 
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Ha azt szeretnénk, hogy egy valarray megőrizze az értékes adatokat, miközben dinamiku- 
san növekszik, ideiglenes változót kell használnunk: 


void grou(valarraysint-kg v, size tn) 


( 


if (n£-v.sizeO) return; 
valarrayszint: tmp(n); // n alapértelmezett elem 


copy(át vlO/,£ vlv.sizeO], ktmploD; // másoló algoritmus §18.6.1-ből 
v.resize(n); 
copy(k tmplol,£tmplv.sizeO],k vIOD); 


A valarray típust nem az ilyen felhasználási területekre tervezték. Egy valarray objektum- 
nak nem illik megváltoztatnia méretét, miután a kezdeti helyfoglalás megtörtént. 


A valarray elemei egyetlen sorozatot alkotnak, tehát a 2/07,.. . ,uln-1/ elemek egymás után 
találhatók a memóriában. Ebből következik, hogy a 7" egy közvetlen elérésű (random- 
access) bejáró (iterátor, §19.2.1) a valarrayST- vektorhoz, így a szabványos algoritmusok, 
például a copyO, alkalmazhatók rá. Ennek ellenére jobban illik a valarray szellemiségéhez, 
ha a másolást értékadások és résztömbök formájában fejezzük ki: 

void gyrow2X(valarraycint2eg v, size tn) 

( 


if (n£-v.sizeO) return; 


valarraysint: tmp — u; 


slice s(O,v.sizeO), DUD; // v.sizeO) elemszámú résztömb (lásd §22.4.5) 
v.resize(n); // az átméretezés nem őrzi meg az elemek értékét 
uls] - tmp; // elemek visszamásolása v első részébe 

j 


Ha valamilyen okból a bemeneti adatok olyan elrendezésűek, hogy be kell azokat olvas- 
nunk, mielőtt megtudnánk a tárolásukhoz szükséges vektor méretét, általában érdemes elő- 
ször egy vector (§16.3.5) objektumba olvasni az elemeket és onnan másolni azokat egy 


valarray változóba. 
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22.4.4. Nem tagfüggvényként megvalósított műveletek 


A szokásos bináris (kétoperandusú) operátorok és matematikai függvények így szerepel- 
nek a könyvtárban: 


templatexclass T: valarrayST: operator" (const valarrayST-£k, const valarrayST:£ ); 
templatexclass T: valarraycT: operator" (const valarraysT:£, const I£); 
templatexclass T: valarrayST: operator"(const Tk, const valarrayszT-£ ); 








// hasonlóan: /, 96, 4, -, N, k, I, cc, 25, £k, II, ——, /-, c, 3, c-, 5-, atan2, és bow 
templatexclass T- valarrayST: abs(const valarrayzT:£ ); 
// hasonlóan: acos, asin, atan, cos, cosh, exp, log, log10, sin, sinh, sgrt, tan, és tanh 

A bináris műveleteket két valarray objektumra, vagy egy valarray objektum és a megfele- 


lő típusú skalár érték együttesére alkalmazhatjuk: 


void fvalarrayzdoublezxk v, valarrayzdoublezk v2, double d) 


( 
valarraySdouble: v3 — vtuv2; 7 v3[íj — uvlifrv2[i] minden i-re 
valarraySdouble: vá — vtd; // váli] - ulif"d minden i-re 
valarrayzdouble: v5 — d7v2; // v5li] - d7v2li] minden i-re 
valarrayzdouble:z v6 — cos(v); // vóli] — cos(aliJ) minden i-re 


Ezek a vektorműveletek valarray operandusuk Coperandusaik) minden elemére végrehajt- 
ják a megfelelő műveletet, úgy, ahogy a " és a cos példákon keresztül bemutattuk. Ter- 
mészetesen minden művelet csak akkor alkalmazható, ha a megfelelő függvény definiált 
a sablonparaméterként megadott típusra. Ellenkező esetben a fordító hibaüzenetet ad, ami- 
kor megpróbálja példányosítani a sablont (413.59. 


Ha az eredmény egy valarray, akkor annak hossza megegyezik a paraméterlek)ben hasz- 
nált valarray méretével. Ha két valarray paraméter mérete nem egyezik meg (bináris mű- 
veletnél), az eredmény nem meghatározott lesz. 


Érdekes módon [/O műveletek nem állnak rendelkezésünkre a valarray típushoz (§22.4.39; 
a CZ és a 55 operátor csak léptetésre szolgál. Ha mégis szükségünk van a két operátor ki- 
és bemenetet kezelő változatára, minden gond nélkül definiálhatjuk azokat (§22.915D. 


22. Számok 901 


Jegyezzük meg, hogy ezek a valarray műveletek új valarray objektumokat adnak vissza, 
és nem operandusaikat módosítják. Ez egy kicsit , költségesebbé" teheti a függvényeket, de 
ha kellően hatékony optimalizációs módszereket alkalmazunk, ez a veszteség nem jelent- 
kezik (ásd például §22.4.7). 


A valarray objektumokra alkalmazható operátorok és matematikai függvények ugyanúgy 
használhatók slice array (§22.4.69, gslice array (§22.4.8), mask array (§422.4.9) és 
indirect array (§22.4.10) objektumokra is, egyes nyelvi változatok azonban lehet, hogy 
a nem valarray típusú operandusokat először valarray típusra alakítják, majd ezen végzik 
el a kijelölt műveletet. 


22.4.5. Szeletek 


A slice (szele) olyan elvont típus, amely lehetővé teszi, hogy vektorokat akárhány dimen- 
ziós mátrixként hatékonyan kezeljünk. Ez a típus a Fortran vektorok alapeleme és kulcssze- 
repet játszik a BLAS (Basic Linear Algebra Subprograms) könyvtárban, amely viszont a leg- 
több számművelet kiindulópontja. A szelet alapjában véve nem más, mint egy valarray egy 
részletének minden n-ik eleme: 


class std::slice f 
// kezdőindex, hossz, és lépésköz 


bublic: 

sliceO; 

slice(size t start, size t size, size t stride); 

size t start) const; // az első elem indexértéke 

size t size0 const; // elemek száma 

size t strideO const; // az n-ik elem helye: startO-tn"strideO 
h 


A stride a lépésköz, vagyis a távolság (az elemek számában kifejezve) a s/lice két, egymást 
követő eleme között. Tehát a s/ice egészek egy sorozatát írja le: 


size t slice index(const slicek s, size ti) // i leképezése a megfelelő indexértékre 
( 
return s.startO-xi"s.strideO; 
) 
void print seg(const sliceg s) // s elemeinek kiírása 
( 


for (size t i — O; ics.sizeO); it4) cout cz slice index(s,i) cz " !; 


J 
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void JO 

( 
print seg(slice(0,3,49; // 0. sor 
cout cz ", T; 
print seg(sliceC1,3,99; // 1. sor 
cout cz ", T; 
print seg(slice(0,4, 19; // 0. oszlop 
cout cz ", T; 
print seg(slice(4, 4, 19; // 1. oszlop 


A megjelenő szöveg a következő lesz: 048, 159,0123,4567 


Tehát egy slice nem tesz mást, mint hogy nemnegatív egész értékeket sorszámokra képez 
le. Az elemek száma (sizeO) nincs hatással a leképezésre (a címzésre), de lehetőséget ad 
számunkra a sorozat végének megtalálására. Ez a leképezés egy egyszerű, hatékony, álta- 
lános és viszonylag kényelmes lehetőséget ad egy kétdimenziós tömb utánzására egy egy- 
dimenziós tömbben (például egy valarray objektumban). Például lássunk egy 3-szor 4-es 
mátrixot abban a formában, ahogy megszoktuk (4C.79: 























A Fortran szokásainak megfelelően ezt a következő formában helyezhetnénk el a memóriában: 
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A C4t4 nem ezt a megoldást használja (lásd §C.7), ugyanakkor biztosítanunk kell egy 
rendszert, amely tiszta és logikus kezelőfelületet ad, és ehhez olyan ábrázolást kell válasz- 
tanunk, amely megfelel a probléma kötöttségeinek. Itt most a Fortran elrendezését válasz- 
tottam, hogy könnyen megvalósítható legyen az együttműködés az olyan numerikus prog- 
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ramokkal, melyek ezt az elvet követik. Annyira azért nem voltam hajlandó változtatni, hogy 
az indexelést 0 helyett 7-ről indítsam — ha ilyen céljaink vannak, oldjuk meg a §22.919] fel- 
adatot. A legtöbb számműveletet továbbra is számos nyelv és még több könyvtár együttes 
használatával kell megoldanunk. A különböző nyelvek és könyvtárak eltérő formátumú 
adatainak kezelése gyakran létszükséglet. 


Egy x sort a slice(x, 3, 4) kifejezéssel írhatunk le. Tehát az x sor első eleme a vektor xx -ik ele- 
me, a sor következő eleme az (xt4J-ik és így tovább. A fenti példában minden sor három 
elemet tartalmaz. Az ábrák szerint a slice(0,3,4) a 00, a 01 és a 02 elemet jelöli. 


Egy y oszlopot a slice(4"y, 4, 1) határoz meg. Az y oszlop első eleme a vektornak £7y-ik ele- 
me, a következő oszlopelem a (47yt 10-ik vektorelem stb. Minden oszlopban áÁ elem szere- 
pel. A slice(O, 4, 1) kifejezés tehát az ábrák szerint a 00, a 10, a 20és a 30 elemet jelöli. Azon 
kívül, hogy könnyen utánozhatunk kétdimenziós tömböket, a s/lice segítségével számtalan 
más sorozatot is leírhatunk; az egyszerű sorozatok megadására így kellően általános mód- 
szert biztosít. Ezzel a §422.4.8 pont foglalkozik részletesen. 


Egy szeletet elképzelhetünk úgy is, mint egy különleges bejárót (iterator): a slice lehetővé 
teszi, hogy leírjunk egy indexsorozatot egy valarray objektumban. Ez alapján egy valódi 
bejárót is felépíthetünk: 


templatexclass T- class Slice iter ( 
valarrayzT2? u; 
slice s; 
size t curr: // az aktuális elem indexe 


Ig refrsize ti) const ( return (v)ls.startO-ti"s.strideO); ) 
bublic: 


Slice iter(valarrayzT2" wvu, slice ss) :v(vuv), s(ss), curr(0) ( ) 


Slice iter endŐ 


( 
Slice iter t — "this; 
t.curr — s.sizeO; // az utolsó utáni elem indexértéke 
return t; 

) 


Slice iterg operatort40 (f curr44; return "this; ) 
Slice iter operator4-(int) f Slice iter t — "this; curr4-4; return t; ) 


Ik operatorf [(size t i) ( return ref(curr-i); ) // C stílusú index 

Ik operatorOcsize ti) f return ref(curr-i); ) // Fortran stílusú index 
Ik operator? ( return ref(curr); ) // az aktuális elem 
V/ANOS 
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Mivel a slice rögzített méretű, tartományellenőrzést is végezhetünk. A fenti példában 
a slice::size0) kihasználásával valósítottuk meg az endŐ műveletet, hogy a valarray utolsó 
utáni elemére állíthassuk a bejárót. 


A slice leírhat egy sort és egy oszlopot is, így a S/ice iter is lehetővé teszi, hogy akár egy 
sort, akár egy oszlopot járjunk be a valarray objektumban. 


Ahhoz, hogy a SZice iter igazán jól használható legyen, meg kell határoznunk az ——, a /- és 
a C operátott is: 


templatexclass T- bool operator-—(const Slice iteréT-k p, const Slice iterzT:k ag) 


( 
return p.curr--g.curr k£ p.s.stride0-—-g.s.stride0 kk p.s.startO—-g.s.startO; 


j 


templatexclass T: bool operator/—(const Slice iteréT-k p, const Slice itercT-k ag) 


( 
return (p--9; 


j 


templatexclass T- bool operators(const Slice iterzéT:k p, const Slice itersT-k ag) 


( 
return p.currZg.curr ké p.s.stride0—-g.s.stride0) ké p.s.startO0-—-g.s.startO; 


j 


22.4.6. A slice array 


A valarray és a slice felhasználásával olyan szerkezetet építhetünk, amely úgy néz ki és úgy 
is viselkedik, mint egy valarray, pedig valójában csak a szelet által kijelölt területre hivat- 
kozik. Ezt a slice array típust a következőképpen definiálhatjuk: 


template cclass T- class std::slice array f 
bublic: 
typedef T value type; 


void operator-(const valarrayST:£ ); 
void operator—(const Ik val; // minden elem val-t kapja értékül 


void operatort—(const Ik vaD; /7 vlif"-val minden elemre 
// hasonlóan: /-, 90-, 4-, -—— M- £-, ]- ccz 55- 
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-slice arrayO; 


Private: 
slice arrayO; // létrehozás megakadályozása 
slice array(const slice arrayé£ ); // másolás megakadályozása 


slice arrayk operator—(const slice arrayk);  // másolás megakadályozása 


valarrayST2? p; // megvalósítástól függő ábrázolás 
slice s; 


VE 


A felhasználók nem hozhatnak létre közvetlenül egy s/lice array objektumot, csak egy 
valarray ,indexelésével" az adott szeletre. Miután a slice array objektumnak kezdőértéket 
adtunk, minden rá történő hivatkozás közvetve arra a valarray objektumra hat majd, amely- 
hez létrehoztuk. Az alábbi formában például egy olyan szerkezetet hozhatunk létre, amely 
egy tömb minden második elemét választja ki: 


void Kvalarrayzdoublezk d) 


f 
slice arrayzdoublez£k v even - díslice(O,d.size/25d.size0902, 20]; 
slice arrayzdoublez£k v odd — disliceC1,d.size0/2, 20]; 


v even"- v odd; // az elempárok szorzatát tároljuk a páros elemekben 
v odd — 0; // 0 értékül adása a páratlan elemeknek 


J 


A slice array objektumok másolását nem engedhetjük meg, mert csak így tehetjük lehető- 
vé olyan optimalizációs módszerek alkalmazását, melyek kihasználják, hogy egy objektum- 
ra csak egyféleképpen, álnevek nélkül hivatkozhatunk. Ez a korlátozás néha nagyon kelle- 
metlen: 


slice arrayzdouble: rou(valarrayzdoublexkg d, int i) 


f 
slice arraycdouble: v — dlislice(O, 2,d.size0/ 20]; // hiba: másolás kísérlete 


return díslice(i902,i,d.size0/2]; // hiba: másolás kísérlete 


J 


Egy slice array másolása gyakran helyettesíthető a megfelelő s/ice másolásával. 


A szeletek alkalmasak a tömbök bizonyos típusú részhalmazainak kifejezésére. A követke- 
ző példában például szeleteket használunk egy folytonos résztartomány kezeléséhez: 
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inline slice sub arraycsize t first, size t counD) // (first:first4:count[ 


( 


return slice(first, count, 1); 


j 


void fwvalarrayzdoublex£g v) 
( 

size t sz — v.sizeO; 

if (sz£2) return; 

size tn — s2/2; 

size t n2 -— sz-n; 


valarrayzdouble: halfi(n); 
valarrayZdouble: half2(n29; 


halfi - ulsub array(On)]; // v első felének másolása 
half2 - vlsub array(n,n2)]; // v második felének másolása 
Ms 


A standard könyvtárban nem szerepel mátrix osztály. Ehelyett a valarray és a slice együtte- 
sen igyekszik biztosítani azokat az eszközöket, melyekkel különböző igényekhez igazított 
mátrixokat építhetünk fel. Nézzük meg, hogyan készíthetünk egy egyszerű, kétdimenziós 
mátrixot a valarray és a slice array felhasználásával: 


class Matrix f 
valarrayZdoublez? u; 
size t d1, d2; 
bublic: 
Matrix(Csize t x, size t y); // megjegyzés: nincs alapértelmezett konstruktor 
Matrix(const Matrixdt ); 
Matrixk operator-(const Matrix£ ); 
-MatrixO; 


size t sizeO const f return d1"d2; ) 
size t dim10O const f return d1; ) 
size t dim20 const f return d3; ) 


Slice itercdoublez rowcsize ti); 
Cslice itercdouble:z rowcsize ti) const; 


Slice itercdoublez columncsize t ii); 
Cslice itercdoublez columncsize t i) const; 


doublek operatorOCsize t x, size ty); // Fortran stílusú index 
double operatorOCcsize t x, size t y) const; 
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Slice iterzdouble: operatorO size t i) f return row(i); ) 
Cslice iterzdouble: operatorOcsize t i) const f( return row(i); ) 


Slice iterzdouble: operatorf [size t i) f return row(i); ) // C stílusú index 
Cslice itercdoublez operatorl Ksize t i) const f return row(i); ) 


Matrixk operatort-(double); 


valarraysdoublezk arrayO ( return ?v; ) 


35 


A Matrix-ot egy valarray ábrázolja. Erre a tömbre a kétdimenziós jelleget a szeletelés segít- 
ségével ,húzhatjuk rá". Ezt az ábrázolást tekinthetjük egy-, két-, három- stb. dimenziós 
tömbnek is, ugyanúgy, ahogy az alapértelmezett kétdimenziós nézetet biztosítjuk a rowO 
és a columnO függvény megvalósításával. A S/ice iter objektumok segítségével megkerül- 
hetjük a slice array objektumok másolásának tilalmát. Egy slice array típusú objektumot 
nem adhatunk vissza: 


slice arrayzdouble: roucsize ti) f return ("v)(slice(i,d1,d299; ) // hiba 


Ezért a slice array helyett egy bejárót (iterator) adunk meg, amely egy mutatót tartalmaz 
a valarray objektumra, illetve magát a slice objektumot. 


Meg kell határoznunk egy további osztályt is, a ,bejárót a konstans szeletekhez". Ez 
a Cslice iter, amely egy const Matrix és egy nem konstans Matrix szeletei közötti különb- 
séget fejezi ki. 


inline Slice iterzdouble: Matrix::row(size t i) 


( 


return Slice itercdouble:(v,slice(i,d1,d2)); 


J 


inline Cslice itercdouble: Matrix::row(size t i) const 


( 


return Cslice iterzdoublex(w,slice(i,d1,d2)); 


J 


inline Slice itercdouble: Matrix::column(size ti) 


( 


return Slice iterzdouble:(v,slice(i"d2, d2, 19; 


J 


inline Cslice itercdouble: Matrix::column(size t i) const 


( 


return Cslice iterzdoublex(wv,slice(i"d2,d2, 19; 


J 
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A Cslice iter definiciója megegyezik a S/ice iter-ével, a különbség mindössze annyi, hogy 
itt a szelet elemeire const referenciák fognak mutatni. 


A többi tagfüggvény meglehetősen egyszerű: 


Matrix:: Matrix(size t x, size ty) 


( 
// ellenőrzés: x és y értelmes-e 
d1 — x; 
d2 - y; 


v - new valarrayzdoublex(x?y); 


J 


doublek Matrix::operatorO(size t x, size t y) 


( 


return rowCx)[y]; 


J 


double mukcCslice iterzdoublezk v1, const valarrayzdoublezk v2) 


double res — 0; 
for Csize t i — O; iZv1.sizeO; 1334) rest — vIlifrv2[ij; 
return res; 


j 


valarrayZdouble: operator" (const Matrixdt m, const valarrayzdoublezk v) 
( 

valarraycdouble: res(m.dim109; 

for (size t i - O; icm.dim10); ira) res[í/ - mul(rm.row(),v); 

return res; 
2 


J 
Matrixk Matrix::operator"-(double d) 


( 
(ty) t- d; 
return "this; 


j 


A Matrix indexeléséhez az (ij) jelölést használtam, mert a ( ) egy elég egyszerű operátor, 
és ez a jelölés a , matematikus társadalomban" eléggé elfogadott. A sor fogalma ennek elle- 
nére lehetővé teszi a C és C4- világban megszokottabb /i/[// jelölést is: 


void ((Matrixk m) 

( 
m(1,2) - 5; // Fortran stílusú index 
m.rou(11(2) - 6; 
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m.row(1)/2] — 7; 
m[1JO) - 8; // zavaros, kevert stílus (de működik) 
m(1][[2] - 9; // C44 stílusú index 

) 


Ha a slice array osztályt használjuk az indexeléshez, erős optimalizálásra van szükségünk. 


Ennek a szerkezetnek az általánosítása n-dimenziós mátrixra és tetszőleges elemtípusra 
a megfelelő művelethalmaz biztosításával a 422.9[7] feladat témája. 


Elképzelhető, hogy első ötletünk a kétdimenziós vektor megvalósítására a következő volt: 


class Matrix f 

valarrayz£ valarrayzdouble: : u; 
bublic: 

VAS 
j; 


Ez a megoldás is működőképes (422.9I10D, de így igen nehéz anélkül összeegyeztetni a haté- 
konyságot a nagyteljesítményű számítások által megkívánt követelményekkel, hogy 
a valarray és a slice osztály által ábrázolt alacsonyabb és hagyományosabb szintre térnénk át. 


22.4.7. Ideiglenes változók, másolás, ciklusok 


Ha megpróbálunk készíteni egy vektor vagy egy mátrix osztályt, rövid időn belül rájöhe- 
tünk, hogy három, egymással összefüggő problémát kell figyelembe vennünk a teljesít- 
ményt hangsúlyozó felhasználók igényeinek kielégítéséhez: 


1. Az ideiglenes változók számát a lehető legkisebbre kell csökkentenünk. 

2. A mátrixok másolásának számát a lehető legkisebbre kell csökkentenünk. 

3. Az összetettebb műveletekben az ugyanazon adatokon végighaladó ciklusok 
számát a lehető legkisebbre kell csökkentenünk. 


A standard könyvtár nem közvetlenül ezekkel a célokkal foglalkozik. Ennek ellenére léte- 
zik olyan eljárás, melynek segítségével optimális megoldást biztosíthatunk. 


Vegyük például az U-M"Vt W műveletet, ahol U, Vés W vektor, M pedig mátrix. A legegy- 
szerűbb megoldásban külön-külön ideiglenes változóra van szükségünk az M"V és az 
M"V: W számára, és másolnunk kell az MV és az M"VtW eredményét is. Egy ,okosabb" 
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változatban elkészíthetjük a mul add and assign(kU, kM, £ V, £ W7 függvényt, amely- 
nek nincs szüksége ideiglenes változókra, sem a vektorok másolására, és ráadásul minden 
mátrix minden elemét a lehető legkevesebbszer érinti. 


Ilyen mérvű optimalizálásra egy-két kifejezésnél többször ritkán van szükségünk. Így a ha- 
tékonysági problémák megoldására a mul add and assignŐ jellegű függvények írása, az 
egyik legegyszerűbb módszer melyeket a felhasználó szükség esetén meghívhat. Ugyanak- 
kor lehetőség van olyan Matrix kifejlesztésére is, amely automatikusan alkalmaz ilyen 
optimalizációt, ha a kifejezéseket megfelelő formában fogalmazzuk meg. A lényeg az, hogy 
az U-M"V1 W kifejezést tekinthetjük egyetlen, négy operandussal rendelkező operátor al- 
kalmazásának. Az eljárást már bemutattuk az ostream módosítóknál (421.4.6.3). Az ott be- 
mutatott módszer általánosan használható arra, hogy n darab kétoperandusú operátor 
együttesét egy (111) paraméterű operátorként kezeljük. Az U-M"V: W kifejezés kezelésé- 
hez be kell vezetnünk két segédosztályt. Ennek ellenére bizonyos rendszerekben ez a eljá- 
rás igen jelentős (akár 30-szoros) sebességnövekedést is elérhet azzal, hogy további opti- 
malizálást tesz lehetővé. 


Először is meg kell határoznunk egy Matrix és egy Vector szorzásakor képződő eredmény 
típusát: 


struct MVmul ( 
const Matrixk m; 
const Vectorg U; 


MVmukconst Matrixk mm, const Vector $vv) :m(mm), v(wv) f ) 


operator VectorO; // az eredmény kiszámítása és visszaadása 


3 


inline MVmul operator? (const Matrixk mm, const Vectorgt vv) 


( 


return MVmul(mm, vv); 


j 


A , szorzás" semmi mást nem tesz, mint hogy referenciákat tárol az operandusairól; az MV 
tényleges kiszámítását későbbre halasztjuk. Az objektum, amelyet a " művelet eredményez, 
igen közel áll ahhoz, amit gyakran lezárás (closure; inkább , befoglaló objektum") néven 
emlegetnek. Ugyanígy kezelhetjük egy Vector hozzáadását az eddigi eredményhez: 


struct MVmulVadd f 
const Matrixk m; 
const Vectorg U; 
const Vectorkg v2; 
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MVmulVadd(const MVmulk mu, const Vectorgt vu) :m(mv.m), u(rmvu.v), U2X(vv) f ? 


operator VectorO; // az eredmény kiszámítása és visszaadása 


Va 


inline MVmulVadd operatort(const MVmulk mu, const Vectorg vu) 


( 
return MVmulVadd(mu, vu); 
V4 


Ezzel az M"Vt W kifejezés kiszámítását is elhalasztjuk. Most már csak azt kell biztosítanunk, 
hogy hatékony algoritmussal számoljuk ki a tényleges eredményt, amikor a kifejezés ered- 
ményét értékül adjuk egy Matrix objektumnak: 


class Vector f 


le 
bublic: 
Vector(const MVmulVadd£ m) // kezdeti értékadás m eredményével 
J 
t 
// elemek lefoglalása, stb. 
mul add and assign(this,km.m,dm.v,km.v29; 
) 
Vectork operator-(const MVmulVaddk m)  // m eredményének értékül adása "this-nek 
( 
mul add and assign(this,km.m,dm.v,km.v29; 
return "this; 
) 
FAR 
$; 


Így tehát az U-Mt Vt: W kifejezés automatikusan a következő kifejezésre változik: 


U.operator-(MVmulVadd(MVmuKk(M, V), W)) 


Ezt pedig a helyben kifejtés alkalmazása az eredeti, megkívánt függvényhívásra alakítja: 


mul add and assign(kU,£M,£ V,£ W) 


Ezzel a megoldással kiküszöböltük a másolásokat és az ideiglenes változókat, ráadásul 
a mul add and-assignŐ függvényen további optimalizálást is végrehajthatunk. Sőt, ha 
a mul add and assignŐ függvényt a lehető legegyszerűbb módon készítjük el, akkor is 
olyan formát alakítottunk ki, amely az automatikus optimalizáló eszközök számára sokkal 
kedvezőbb. 
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A fenti példában egy új Vector típust használtunk (nem az egyszerű valarray osztályt), mert 
új értékadó operátorokat kellett meghatároznunk és az értékadásoknak mindenképpen tag- 
függvényeknek kell lenniük (411.2.29. Nagy valószínűséggel azonban a valarray osztályt 
használjuk a Vector megvalósításához. Ennek a módszernek abban áll a jelentősége, hogy 
a leginkább időigényes vektor- és mátrixműveletek elvégzését néhány egyszerű nyelvi elem- 
mel fogalmazzuk meg. Annak igazán soha sincs értelme, hogy így optimalizáljunk egy féltucat 
operátort használó kifejezést, ezekre a hagyományosabb eljárások (411.6) is megfelelőek. 


Az ötlet lényege, hogy fordítási idejű vizsgálatokat végzünk és befoglaló objektumokat 
Cclosure) használunk, azzal a céllal, hogy a részkifejezések kiszámítását a teljes műveletet 
ábrázoló objektumra bízzuk. Az elv számos területen használható; lényege, hogy több önál- 
ló információelemet egyetlen függvénybe gyűjtünk össze, mielőtt a tényleges műveleteket 
elkezdenénk. A késleltetett kiszámítás érdekében létrehozott objektumokat kompozíciós le- 
zárt (befoglaló) objektumoknak (composition closure object?) vagy egyszerűen kompo- 
zitoroknak (compositor) nevezzük. 


22.4.8. Általánosított szeletek 


A §22.4.6 pontban szereplő Matrix példa megmutatta, hogyan használhatunk két sZice ob- 
jektumot egy kétdimenziós tömb sorainak és oszlopainak leírására. Általánosan az igaz, 
hogy egy slice alkalmas egy n-dimenziós tömb bármely sorának vagy oszlopának kijelölé- 
sére (422.9[7D, de néha szükségünk lehet olyan résztömb kijelölésére is, amely nem egyet- 
len sora, vagy egyetlen oszlopa az n-dimenziós tömbnek. Tegyük fel, hogy egy 3-szor 4-es 
mátrix bal felső sarkában elhelyezkedő 2-szer 3-as részmátrixot akarunk kijelölni: 






































Sajnos ezek az elemek nem úgy helyezkednek el a memóriában, hogy egy slice segítségé- 
vel leírhatnánk azokat: 
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A gslice egy olyan általánosított s/ice, amely (majdnem) n darab szelet információit tartalmazza: 


class std::gslice ( 
// ahelyett, hogy a slice-hoz hasonlóan 1 lépésköz és 1 méret lenne, 
// a gslice-ban n lépésköz és n méret van 


bublic: 
gsliceO; 
gslice(size t s, const valarraycsize t2£g I, const valarrayssize t2k d); 
size t start const; // az első elem indexértéke 
valarrayssize t2 sizeO const; // elemek száma a dimenzióban 
valarrayssize t2 strideO const; // lépésköz index[0], index[1], ... között 


Az új értékek lehetővé teszik, hogy a gslice leképezést határozzon meg n darab egész és 
egy index között, amit a tömb elemeinek eléréséhez használhatunk fel. Egy 2-szer 3-as mát- 
rix elhelyezkedését például két (hosszúság, lépésköz) elempárral írhatjuk le. A §22.4.5 pont- 
ban bemutattuk, hogy a 2 hosszúság és a 4 lépésköz a 3-szor 4-es mátrix egy sorának két 
elemét írja le, ha a Fortran elrendezését használjuk. Ugyanígy, a 3 hosszúság és az 7 lépés- 
köz egy oszlop 3 elemét jelöli ki. A kettő együtt képes leírni egy 2-szer 3-as részmátrix 
összes elemét. Az elemek felsorolásához az alábbi eljárásra lesz szükségünk: 


size t gslice index(const gslicek s, size ti, size tj) 


f 
return s.startO-ri"s.strideO[0Ja-j"s.strideO[1]; 
J 
size t len[] - ( 2, 527; // denlo/ strlO)) egy sort ír le 
size tsttJ-€4 1); // Genl1] strl1)) egy oszlopot ír le 


valarrayssize t- lengths(len, 29; 
valarrayssize t2 strides(str, 29; 


void JO 
( 
gslice s(O,lengths,strides); 
for Gnt i - 0 ; iSs.sizeO [0]; it) cout cz gslice index(s,i,0) cz " !; // sor 
cout cz "TT; 
for (int j -— 0 ; jés.sizeO[1]; jt1) cout cc gslice index(s,0j) cz " T; // oszlop 


J 


Az eredmény 0 4 , 0 1 2lesz. 


914 A standard könyvtár 


Ezzel a módszerrel egy gslide két (hosszúság, lépésköz) pár segítségével képes megadni 
egy kétdimenziós tömb tetszőleges részmátrixát. Három (hosszúság, lépésköz) párral leír- 
hatjuk egy háromdimenziós tömb résztömbjeit és így tovább. Ha egy gslice objektumot 
használunk egy valarray indexeléséhez, akkor egy gslice arraytípusú objektumot kapunk, 
ami a gslice által kijelölt elemeket tartalmazza. Például: 


void fvalarraysfloat:£ v) 


gslice m(O,lengths,strides); 


ulm] — 0; // értékül adja 0-t vlOJ,v[ 1], v2], vlál, ul 57], vI6] elemeknek 
2 


J 
A gslice array ugyanazokat a tagfüggvényeket biztosítja, mint a slice array, így egy 
gslice array objektumot sem hozhat létre közvetlenül a felhasználó, és nem is másolhatja 
(422.4.6), viszont gslice array objektumot kapunk eredményként, ha egy valarray (§22.4.2) 
objektumot egy gs/ice objektummal indexelünk. 


22.4.9. Maszkok 


A mask array típus a valarray tömb valamely része kijelölésének másik módja. Ráadásul 
az eredményt is egy valarray-szerű formában kapjuk meg. A valarray osztály szempontjá- 
ból a maszk egyszerűen egy valarraycbool: objektum. Amikor maszkot használunk egy 
valarray indexeléséhez, a true bitek jelzik, hogy a valarray megfelelő elemét az eredmény- 
ben is meg szeretnénk kapni. Ez a megoldás lehetővé teszi, hogy egy valarray objektum- 
nak olyan részhalmazát dolgozzuk fel, amely nem valamilyen egyszerű elrendezésben (pél- 
dául egy szeletben) helyezkedik el: 


void fwalarrayzdoublexg v) 


bool b[ J -— f true , false, false, true, false, true ) ; 
valarraySbool: mask(b, 69; // a O, 3, és 5 elem 


valarrayzdouble: vu -— cos(ulmask)); // vvul[0]J-—cos(u[0J), vu[1]J--cos(u[3)), 
// vu[2]J--cos(ul 5 


A mask array osztály ugyanazokat a műveleteket biztosítja, mint a slice array. Egy 
mask array objektumot sem hozhatunk létre közvetlenül, és nem is másolhatjuk (422.4.6). 
Egy mask array meghatározásához egy valarray (§422.4.2) objektumot kell indexelnünk 
valarraySbool: objektummal. A maszkoláshoz használt valarray mérete nem lehet na- 
gyobb, mint azon valarray elemeinek száma, amelyben ezt indexelésre akarjuk használni. 
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22.4.10. Indirekt tömbök 


Az indirect array (indirekt vagyis közvetett tömb) lehetőséget ad arra, hogy egy valarray 
objektumot tetszőlegesen indexeljünk és átrendezzünk: 


void fvalarrayzdoublex£g v) 


size ti([]-( 3, 2, 1, 02; // az első 4 elem fordított sorrendben 
valarrayssize t- indexG, 4); // a 3, 2, 1, 0 elemek (ebben a sorrendben) 
valarrayZdouble: uv - log(ilindex)); // vu[0J--log(l3D), vul1]/--log(ul2D, 


// vul2]--logal1)), vul3]/--log(vloD 
J 


Ha egy sorszám kétszer szerepel, akkor a valarray objektum valamely elemére kétszer hi- 
vatkozunk egy műveleten belül. Ez pontosan az a típusú többszörös hivatkozás (álnév), 
amit a valarray nem enged meg. Így az indirect array működése nem meghatározott, ha 
többször használjuk ugyanazt az indexértéket. 


Az indirect array osztály ugyanazokat a műveleteket biztosítja, mint a slice array, tehát 
nem hozhatunk létre közvetlenül indirect array objektumokat, és nem is másolhatjuk azo- 
kat (§422.4.09; erre a célra egy valarray (§22.4.2) objektum valarraycsize t2 objektummal 
való indexelése szolgál. 


22.5. Komplex aritmetika 


A standard könyvtár tartalmaz egy complex sablont, körülbelül azokkal a tulajdonságokkal, 
amelyekkel a §11.3 pontban szereplő complex osztályt meghatároztuk. A könyvtárban sze- 
replő complex osztálynak azért kell sablonként (template) szerepelnie, hogy különböző 
skalár típusokra épülő komplex számokat is kezelni tudjunk. A könyvtárban külön-külön 
változat szerepel a float, a double és a long double skalártípushoz. 


A complex osztály az std névtérhez tartozik és a ccomplex: fejállomány segítségével érhető el: 


templatexclass T- class std::complex f 
T re, im; 

bublic: 
typedef T value type; 
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complex(const Ik r - TO, const Ig i - TO) : re(r), im(i) ( ) 
templatezclass X- complex(const complexzxzkg a) : re(a.real0), im(a.imagO) ( ) 


T realó const (f return re; ) 
T imagO const ( return im; ) 


complexZT-k operator—(const I 2); // complex(z,0) értékül adása 
templatexclass X- complexzT:£k operator-(const complexzx2é£ ); 
// hasonlóan: 4—, -——, t- /7 


Az itt bemutatott megvalósítás és a helyben kifejtett (inline) függvények csak illusztráció- 
ként szerepelnek. Ha nagyon akarunk, el tudunk képzelni más megvalósítást is a standard 
könyvtár complex osztályához. Figyeljük meg a sablon tagfüggvényeket, amelyek lehetővé 
teszik, hogy bármilyen típusú complex objektumnak egy másikkal adjunk kezdőértéket, 
vagy azt egyszerű értékadással rendeljük hozzá (413.6.2). 

A könyv folyamán a complex osztályt nem sablonként használtuk, csak ,egyszerű" osztály- 
ként. Erre azért volt lehetőség, mert a névterekkel ügyeskedve a double értékek complex 
osztályát tettük , alapértelmezetté" : 


typedef std::complexzdouble: complex; 


Rendelkezésünkre állnak a szokásos egyoperandusú (unáris) és kétoperandusú (bináris) 
operátorok is: 


templatexclass T- complexZT:- operatort(const complexZT:k, const complexzT:£ ); 
templatexclass T- complexZT:- operatort(const complexzT-:k, const Id ); 
templatexclass T- complexST:- operatort(const Tk, const complexzT-£ ); 


// hasonlóan: -, ", /, ——, és /- 


templatexclass T: complexzT: operatort4(const complexzT-£ ); 
templatexclass T: complexzZT: operator-(const complexzT:£ ); 


A koordináta-függvények a következők: 


templatexcilass T- T reakconst complexzT-£ ); 
templatexclass T- T imag(const complexzT:£ ); 


templatexclass T: complexzT: conj(const complexzT:£ ); 


// polár koordinátarendszer szerinti létrehozás (absO,argO): 
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templatexclass T: complexzT:- polar(const Ik rho, const Ik theta); 


templatexclass T: T abs(const complexzT:£ ); // néha rho a neve 
templatexclass T- T arg(const complexzT:£ J; // néha theta a neve 
templatexclass T- T norm(const complexzT-£ ); // az absO négyzetgyöke 


A szokásos matematikai függvényeket is használhatjuk: 


templatexclass T: complexzT: sin(const complexzT-£ ); 
// hasonlóan: sinh, sgrt, tan, tanh, cos, cosh, exp, log, és log10 


templatexclass T: complexzT: pou(const complexzT-:k , int); 

templatexclass T: complexST: pou(const complexzT-k, const I£ ); 
templatexclass T: complexZT: pou(const complexzT-:k, const complexsT-:£ ); 
templatexclass T- complexsT: pou(const Ik, const complexzT-£ J); 


A ki- és bemeneti adatfolyamok kezelésére pedig a következők szolgálnak: 


templatecciass T, class Ch, class Tr: 

basic istreamzCh,Tr:£ operator:P(basic istreamzCh, Ir:£k, complexzT-£ ); 
templatecxciass T, class Ch, class Tr: 

basic ostreamzZCh,Tr-:£ operatorsz(basic ostreamzCh, Tr:£k, const complexzT-£ ); 


A komplex számok kiírási formája (x,y), míg beolvasásra használhatjuk az x, az (Xx) és az 
(x,y) formátumot is (421.2.3, §21.3.59. A complexcfloat:, a complexzdouble: és 
a complexzlong double: specializációk azért szerepelnek, hogy korlátozzuk a konverziókat 
(§13.6.2) és lehetőséget adjunk az optimalizálásra is: 


templatesz class complexzdouble: f 
double re, im; 

public: 
typedef double value type; 


complex(double r - 0.0, double i - 0.0) : re(r), im) f ) 
complex(const complexsfloat-£ a) : re(a.realO), im(a.imagO) ( ) 


explicit complex(const complexzlong doublexk a) : re(a.real0), im(a.imagO) f ) 


Má 
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Ezek után egy complexsfloat: érték gond nélkül complexzdouble: számra konvertálható, 
de egy complexzlong double: már nem. Ugyanilyen specializációk biztosítják, hogy egy 
complexsfloat- vagy egy complexzdouble: automatikusan konvertálható complexclong 
double: értékre, de egy complexzlong double: nem alakítható , titokban" complexzfloat: 
vagy complexzdoublex számmá. Érdekes módon az értékadások nem ugyanazt a védelmet 
biztosítják, mint a konstruktorok: 


void (complexszfloat: cf, complexzdouble: cd, complexzlong double: cld, complexzint: ci) 


( 


complexzdouble: ci — cf; 
complexzdouble: c2 - cd; 
complexzdouble: c3 — cid; 
complexzdouble: cá(cid); 
complexzdouble: c5 — ci; 


c1 — cid; 
c1 — cf; 
ci — ci; 


// jó 

// jó 

// hiba: esetleg csonkol 

// rendben: explicit konverzió 
// hiba: nincs konverzió 


// rendben, de vigyázat: esetleg csonkol 
// rendben 
// rendben 


22.6. Általánosított numerikus algoritmusok 


A cnumeric: fejállományban a standard könyvtár biztosít néhány általánosított numerikus 
algoritmust is, az Calgorithm: fejállomány (18. fejeze9) nem numerikus algoritmusainak 
stílusában: 





Általánosított numerikus algoritmusok cnumerics 








accumulateO 
inner productO 
bartial sumO 


Egy sorozat elemein végez el egy műveletet. 
Két sorozat elemein végez el egy műveletet. 
Egy sorozatot állít elő egy másik sorozatra alkal- 
mazott művelettel. 

Egy sorozatot állít elő egy másik sorozatra alkal- 
mazott művelettel. 


adjacent differenceO 
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Ezek az algoritmusok egy-egy jellegzetes, gyakran használt műveletet általánosítanak. 
Az egyik például kiszámítja egy sorozat elemeinek összegét, de úgy, hogy bármilyen típu- 
sú sorozatra használhassuk az eljárást, a műveletet pedig, amit a sorozat elemeire el kell vé- 
gezni, paraméterként adjuk meg. Mindegyik algoritmus esetében az általános műveletet ki- 
egészíti egy olyan változat, amely közvetlenül a leggyakoribb operátort használja az adott 
algoritmushoz. 


22.6.1. Az accumulatet() 


Az accumulateg algoritmust felfoghatjuk úgy, mint egy vektor elemeit összegző eljárás ál- 
talánosítását. Az accumulateO algoritmus az std névtérhez tartozik és a cnumeric: fejállo- 
mányból érhetjük el: 


template class In, class T- T accumulate(in first, In last, T init) 


: while (first !1- last) init — init 4 "first4r; // összeadás 
return init; 
J 
template class In, class T, class BinOp: T accumulated first, In last, T init, BinOp op) 
( 
while (first !- last) init — op(init, "firsta-4); // általános művelet 
return init; 
J 


Az accumulateO legegyszerűbb változata egy sorozat elemeit adja össze, az elemekre ér- 
telmezett - operátor segítségével: 


void Kvectorsint:£ price, listsfloat2k incr) 


í 
int i - accumulate(price.beginO, price.endO), 09; // int-be összegzés 
double d — 0; 
d - accumulate(incr.beginO, incr.endO, d); // double-ba összegzés 
V/ANYB 

) 


A visszatérési érték típusát az átadott kezdőérték típusa határozza meg. 
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Gyakran azok az értékek, melyeket összegezni szeretnénk, nem egy sorozat elemeiként áll- 
nak rendelkezésünkre. Ha ilyen helyzetbe kerülünk, akkor az accumulate0 számára meg- 


adható műveletet felhasználhatjuk arra is, hogy az értékeket előállítsuk. A legegyszerűbb 
ilyen eljárás csak annyit tesz, hogy a sorozatban tárolt adatszerkezetből kiválasztja a kívánt 
értéket: 


struct Record (f 
VAS 
int unit price; 
int number. of units; 


J; 


long price(long val, const Recordf r) 


( 


return val 4 r.unit price " rnumber. of units; 
) 


J 
void (const vectorZRecord:£ v) 


( 


cout c£ "Összeg: " c accumulate(v.beginO,v.endO, O price) cz M; 


j 


Az accumulateO szerepének megfelelő műveletet egyes fejlesztők reduce vagy reduction 
néven valósítják meg. 


22.6.2. Az inner product 


Egyetlen sorozat elemeinek összegzése, illetve az ilyen jellegű műveletek nagyon gyakori- 
ak, ugyanakkor a sorozatpárokon ilyen műveletet végző eljárások viszonylag ritkák. 
Az inner. product0 algoritmus meghatározása az std névtérben szerepel, deklarációját pe- 
dig a cnumeric: fejállományban találhatjuk meg: 


template class In, class In2, class T- 

T inner. produck(n first, In last, In2 first2, Tini) 

( 
while (first !- lasD) init — init 4 "firstá4 ? Ffirst24; 
return init; 


j 


template class In, class In2, class T, class BinOp, class BinOp2: 
T inner. produck(n first, In last, In2 first2, T init, BinOp op, BinOp2 op2) 
( 

while (first !- last) init - op(init,op2Cfirsta-4, "first24-4)); 

return init; 


j 
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Szokás szerint, a második sorozatnak csak az elejét kell megadnunk paraméterként. A má- 
sodik bemeneti sorozatról azt feltételezzük, hogy legalább olyan hosszú, mint az első. 


Amikor egy Matrix objektumot egy valarray objektummal akarunk összeszorozni, akkor 
a legfontosabb művelet az inner. product: 


valarraycdouble: operator" (const Matrixd m, valarrayzdoublexk v) 


( 


valarrayzdouble: res(m.dim209; 


for (size t i-O; iczm.dim10; it3) ( 

const Cslice itercdoublezk ri - m.row(i); 

resl[i] - inner. product(ri,ri.endO,kuvlO0/, double(O); 
) 


return res; 


J 


valarrayzdouble: operator" (valarrayzdoublezk v, const Matrixk m) 


( 


valarrayzdouble: res(m.dim109; 


for (size t 1-0; izm.dim20; it3) ( 

const Cslice iterzdoublezk ci - m.column(i); 

res[i) - inner. product(ci, ci.endO, £vIOJ, double(0)9; 
) 


return res; 


J 


Az inner. product (belső szorzab) bizonyos formáit gyakran emlegetjük , pont-szorzás" (dot 
product) néven is. 


22.6.3. Növekményes változás 


A partial sumO és az adjacent differenceO algoritmus egymás fordítottjának (inverzének) 
tekinthető, de mindkettő az inkrementális vagy növekményes változás (incremental 
change) fogalmával foglalkozik. Leírásuk az szid névtérben és a cnumeric: fejállományban 
szerepel: 


template class In, class Out: Out adjacent difference(in first, In last, Out res); 


template class In, class Out, class BinOp: 
Out adjacent difference(in first, In last, Out res, BinOp op); 
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Az a, b, c, d, ... sorozatból például az adjacent differenceO a következő sorozatot állítja 
elő: a, b-a, c-b, d-C, ... 


Képzeljünk el egy sorozatot, amely hőmérséklet-értékeket tartalmaz. Ebből könnyen készít- 
hetünk egy olyan vektort, amely a hőmérséklet-változásokat tartalmazza: 


vectorZdouble: temps; 
void JO 


adjacent difference(temps.beginO, temps.endO,temps.beginO; 


j 


A 17, 19, 20, 20, 17 sorozatból például a 77, 2, 1, O, -3 eredményt kapjuk. 


Megfordítva, a partial sumO azt teszi lehetővé, hogy több növekményes változás végered- 
ményét kiszámítsuk: 


template class In, class Out, class BinOp: 
Out partial sum(in first, In last, Out res, BinOp op) 
( 
if (irst--las) return res; 
tres — first; 
T val — "first; 
while (44-first !- lasb) f 
val - op(val,"firsD; 
k4-tres — val; 
j 


return 4-4res; 


j 


template class In, class Out: Out partial sum(in first, In last, Out res) 


t 
return partial sum(first, last, res plus); // 518.4.3 
J 
Az a, b, c, d, ... sorozatból a bartial sumO a következő eredményt állítja elő: a, a-b, 


a1bitc, atbicid, ... Például: 


void JO 
( 
bartial sum(temps.beginO,temps.endO, temps.beginO 9; 


J 


22. Számok 923 


Figyeljük meg, hogy a partial sumO növeli a res értékét, mielőtt új értéket adna a hivatko- 
zott területnek. Ez lehetővé teszi, hogy a res ugyanaz a sorozat legyen, mint a bemeneti. 
Ugyanígy működik az adjacent differenceO is. Tehát a következő utasítás az a, b, c, d 50- 
rozatot az a, atb, a4bic, atbicid sorozatra képezi le: 


partial sum(v.beginO,v.endO,v.beginO; 


Az alábbi utasítással pedig visszaállíthatjuk az eredeti sorozatot: 


adjacent difference(v.beginO, v.endO, v.beginO); 


Egy másik példa: a partial sumO a 17, 2, 1, O, -3 sorozatból a 17, 19, 20, 20, 17 sorozatot 
állítja vissza. 


Akik szerint a hőmérséklet-változások figyelése csupán rendkívül unalmas részletkérdése 
a meteorológiának vagy a tudományos, laboratóriumi kísérleteknek, azok számára megje- 
gyezzük, hogy a készlettartalékok változásainak vizsgálata pontosan ugyanezen a két mű- 
veleten alapul. 


22.7. Véletlenszámok 


A véletlenszámok fontos szerepet töltenek be igen sok szimulációs és játékprogramban. 
A ccstdlib: és az cstdlib.h: fejállományban a standard könyvtár egyszerű alapot biztosít 
a véletlenszámok előállításához: 


define RAND MAX megvalósítás függő /" nagy pozitív egész "/ 


int randO; // ál-véletlenszám O és RAND MAX között 
int srand(int 1); // a véletlenszám-előállító beállítása i-vel 


Jó véletlenszám-előállító (generátor) készítése nagyon nehéz feladat, ezért sajnos nem min- 
den rendszerben áll rendelkezésünkre jó randO függvény. Különösen igaz ez 
a véletlenszámok alsó bitjeire, aminek következtében a randO9on kifejezés egyáltalán nem 
tekinthető általános (más rendszerre átvihető) módszernek arra, hogy 0 és n-1 közé eső 
véletlenszámokat állítsunk elő. A (doublerrandO)y/RAND MAX):n általában sokkal elfo- 


gadhatóbb eredményt ad. 
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Az srandO függvény meghívásával egy új véletlenszám-sorozatot kezdhetünk a paraméter- 
ként megadott alapértéktől. A programok tesztelésekor gyakran nagyon hasznos, hogy egy 
adott alapértékből származó véletlenszám-sorozatot meg tudjunk ismételni. Ennek ellené- 
re általában a program minden futtatásakor más alapértékről akarunk indulni. Ahhoz hogy 
játékainkat tényleg megjósolhatatlanná tegyük, gyakran szükség van arra, hogy az alapér- 
téket a program környezetéből szerezzük be. Az ilyen programokban a számítógép órája ál- 
tal jelzett idő néhány bitje általában jó alapérték. 


Ha saját véletlenszám-előállítót kell készítenünk, elengedhetetlen az alapos tesztelés 


(422.9[14D. 


Egy véletlenszám-előállító gyakran használhatóbb, ha osztály formájában áll rendelkezé- 
sünkre. Így könnyen készíthetünk véletlenszám-előállítókat a különböző értéktartomá- 
nyokhoz: 


class Randint f // egyenletes eloszlás 32 bites long-ot feltételezve 
unsigned long randx; 
bublic: 
Randint(long s - 0) f randx-s; ) 
void seed(long s) f randx-s; ) 


// bűvös számok: 31 bitet használunk egy 32 bites long-ból: 
long abs(long x) ( return xk 0x 7IIfT 


static double maxO ( return 2147483648.O; ) // figyelem: double 
long drau0 f return randx - randx"1103515245 4 12345; ) 


double fdrawOf( return abs(drawO)/maxO; ) //a [O, 1] tartományban 
long operator00 f return abs(drauwO); ) //a IO pou(2, 31] tartományban 
97 
class Urand : public Randint f // egyenletes eloszlás [O:nl intervallumban 
long n; 
bublic: 


Urand(long nn) f n - nn; ) 


long operator00 f long r - n"fdrawO; return (r--n) ? n-1 : r; ) 


J; 


class Erand : public Randint ( // exponenciális eloszlású véletlenszám-előállító 
long mean; 

bublic: 
Eranddlong m) (f mean-m; ) 
long operatorO0 f return -mean " log( (maxO-drawO)/maxO 4 .59; ) 


J; 
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Íme egy rövid próbaprogram: 
int mainŐ 


Urand drau(109; 

mapcint int: bucket; 

for Gnt i - O; iz 1000000; í3---) bucket[drawO[4--; 
forGant j - O; jz10; j43) cout cz buckeltl[j] Sz Mm; 


J 


Ha nem minden bucket értéke van a 100 000 közelében, valahol valamilyen hibát vétettünk. 


Ezek a véletlenszám-előállítók annak a megoldásnak kissé átalakított változatai, amit a Ct- 


könyvtár legelső megvalósításában (pontosabban az első , osztályokkal bővített C" könyv- 
tárban, §1.4) alkalmaztam. 


22.83. Tanácsok 


[1] A numerikus problémák gyakran nagyon árnyaltak. Ha nem vagyunk 100 száza- 
lékig biztosak valamely probléma matematikai vonatkozásaiban, mindenképpen 
kérjük szakember segítségét vagy kísérletezzünk sokat. §422.1. 

[2] A beépített adattípusok tulajdonságainak megállapításához használjuk 
a numeric limits osztályt. §22.2. 

[3] A felhasználói skalártípusokhoz adjunk meg külön numeric limits osztályt. 
§22.2. 

[4] Ha a futási idejű hatékonyság fontosabb, mint a rugalmasság az elemtípusokra 
és a műveletekre nézve, a számműveletekhez használjuk a valarray osztályt. 
§22.4. 

[5] Ha egy műveletet egy tömb részére kell alkalmaznunk, ciklusok helyett használ- 
junk szeleteket. §22.4.6. 

[6] Használjunk kompozitorokat, ha egyedi algoritmusokkal és ideiglenes változók 
kiküszöbölésével akarjuk növelni rendszerünk hatékonyságát. §422.4.7. 

[71] Ha komplex számokkal kell számolnunk, használjuk az std::complex osztályt. 
422.5. 

[8] Ha egy értéket egy lista elemeinek végignézésével kell kiszámítanunk, akkor 
mielőtt saját ciklus megvalósításába kezdenénk, vizsgáljuk meg, nem felel-e 
meg céljainknak az accumulateO, az inner. bproductO vagy az 
adjacent differenceO algoritmus. 422.6. 
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[9] Az adott eloszlásokhoz készített véletlenszám-előállító osztályok hasznosabbak, 
mint a randO közvetlen használata. §22.7. 
[10] Figyeljünk rá, hogy véletlenszámaink valóban véletlenek legyenek. §22.7. 


22.9. Gyakorlatok 


1. C1.5) Készítsünk egy függvényt, amely úgy viselkedik, mint az applyO, azzal 
a különbséggel, hogy nem tagfüggvény és függvényobjektumokat is elfogad. 

2. C1.5) Készítsünk függvényt, amely csak abban tér el az applyO függvénytől, 
hogy nem tagfüggvényként szerepel, elfogad függvényobjektumokat, és a saját 
valarray paraméterét módosítja. 

3. C2) Fejezzük be a SZice iíter-t (422.4.59. Különösen figyeljünk a destruktor létre- 
hozásakor. 

4. (1.5) Írjuk meg újból a §17.4.1.3 pontban szereplő programot az accumulateO 
felhasználásával. 

5. 02) Készítsük el a cc és a 55 ki-, illetve bemeneti operátort a valarray osztály- 
hoz. Készítsünk egy get arrayO függvényt, amely úgy hoz létre egy valarray 
objektumot, hogy annak méretét is maga a bemenet adja meg. 

6. (2.5) Határozzunk meg és készítsünk el egy háromdimenziós tömböt a megfe- 
lelő műveletek létrehozásával. 

7. €2.5) Határozzunk meg és készítsünk el egy n-dimenziós mátrixot a megfelelő 
műveletek létrehozásával. 

8. C2.5) Készítsünk egy valarray-szetrű osztályt, és adjuk meg hozzá a t ésa " 
műveletet. Hasonlítsuk össze ennek hatékonyságát a saját C$--változatunk 
valarray osztályának hatékonyságával. Ötlet: próbáljuk ki többek között az 
x-0.5"(xtyJ-z kifejezés kiértékelését különböző méretű xx, y és z vektor felhasz- 
nálásával. 

9. C3) Készítsünk egy Fortran stílusú tömböt (például Fort array néven), ahol az 
indexek nem O-tól, hanem 17-től indulnak. 

10.C3) Készítsük el a Matrix osztályt úgy, hogy az egy saját valarray objektumot 
használjon az elemek ábrázolásához (nem pedig egy mutatót vagy referenciát 
a valarray objektumra). 

11. C2.5) Kompozitorok (§22.4.7) segítségével készítsünk egy hatékony többdimen- 
ziós indexelési rendszert a / / jelöléssel. A következő kifejezések mindegyike 
a megfelelő elemeket, illetve résztömböket jelölje ki, méghozzá egyszerű index- 
műveletek segítségével: v1/x/, v2Ixilyi, v2xI, v3lxilyzi, v3Ixilyi, v3Ix/ stb. 
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12. C2) A §22.7 pontban szereplő program ötletének általánosításával írjunk olyan 
függvényt, amely paraméterként egy véletlenszám-előállítót fogad és egyszerű 
grafikus formában szemlélteti annak eloszlását, úgy, hogy segítségével szemlé- 
letesen is ellenőrizhessük a véletlenszám-előállító helyességét. 

13.01) Ha n egy int érték, akkor milyen a (doublerrandO)/RAND MAX)"n kifeje- 
zés eloszlása? 

14. €2.5) Rajzoljunk pontokat egy négyzet alakú területen. Az egyes pontok 
koordináta-párjait az Urand(N) osztály segítségével állítsuk elő, ahol Na megje- 
lenítési terület oldalának képpontban mért hossza. Milyen következtetést von- 
hatunk le az eredmény alapján az Urand által létrehozott véletlenszámok 
eloszlásáról? 


15. 02) Készítsünk egy Normal eloszlású véletlenszám-előállítót Nrand néven. 


Negyedik rész 


Tervezés a C-t -k segítségével 


Ez a rész a programfejlesztés áttogóbb szemszögéből mutatja be a C----t és az általa támo- 
gatott eljárásokat. A hangsúlyt a tervezésre és a nyelv lehetőségein alapuló hatékony meg- 
valósításra fektetjük. 


Fejezetek 


23. Fejlesztés és tervezés 
24. Tervezés és programozás 
25. Az osztályok szerepe 


,  .. Csak most kezdem felfedezni, milyen nehéz a gondolatainkat papírra vetni. Amíg csu- 
pán leírásból áll, elég könnyen megy, de amint érvelni kell, a gondolatok között megfelelő 
kapcsolatokat kell teremteni, világosan és gördülékenyen kell fogalmazni, s ez, mint mon- 
dottam, számomra oly nehézséget jelent, amire nem is gondoltam..." 


(Charles Darwin) 


fás 


Fejlesztés és tervezés 


, Nincs ezüstgolyó." 
(F. Brooks) 


Programépítés s Célok és eszközök se A fejlesztési folyamat e fejlesztés ciklus s Tervezési 
célok s Tervezési lépések s Osztályok keresése s Műveletek meghatározása s Függések 
meghatározása e Felületek meghatározása e Osztályhierarchiák újraszervezése e Modellek 
e Kísérletezés és elemzés e Tesztelés e A programok karbantartása e Hatékonyság " Veze- 
tés s Újrahasznosítás s Méret és egyensúly 9 Az egyének fontossága s Hibrid tervezés s 
Bibliográfia — Tanácsok 


23.1. Áttekintés 


Ez az első a három fejezetből, melyek részletesebben bemutatják a szoftvertermék készí- 
tését, a viszonylag magas szintű tervezési szemléletmódtól azokig a programozási fogal- 
makig és eljárásokig, amelyekkel a C-- a tervezést közvetlenül támogatja. Ez a fejezet 
a bevezetőn és a szoftverfejlesztés céljait és eszközeit röviden tárgyaló §23.3 ponton kívül 
két fő részből áll: 
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423.4 A szoftverfejlesztés folyamatának áttekintése. 
423.5 Gyakorlati tanácsok a szoftverfejlesztői munka megszervezéséhez. 


A 24. fejezet a tervezés és a programozási nyelv közti kapcsolatot tárgyalja, a 25. pedig az osz- 
tályoknak a tervezésben játszott szerepével foglalkozik. Egészében véve a 4. rész célja, hogy 
áthidalja a szakadékot a nyelvfüggetlenségre törekvő tervezés és a rövidlátóan a részletekre 
összpontosító programozás között. Egy nagyobb program elkészítési folyamatában mindket- 
tőnek megvan a helye, de a tervezési szempontok és a használt eljárások között megfelelő 
összhangot kell teremteni, hogy elkerüljük a katasztrófákat és a felesleges kiadásokat. 


23.2. Bevezetés 


A legegyszerűbbek kivételével minden program elkészítése összetett és gyakran csüggesz- 
tő feladat. A programutasítások megírása még az önállóan dolgozó programozó számára is 
csupán egy része a folyamatnak. A probléma elemzése, az átfogó programtervezés, a doku- 
mentálás, a tesztelés és a program fenntartásának, módosításának kérdései, valamint 
mindennek az összefogása mellett eltörpül az egyes kódrészek megírásának és kijavításá- 
nak feladata. Természetesen nevezhetnénk e tevékenységek összességét , programozás- 
nak", majd logikus módon kijelenthetnénk: , Én nem tervezek, csak programozok". Akármi- 
nek nevezzük is azonban a tevékenységet, néha az a fontos, hogy a részletekre összponto- 
sítsunk, néha pedig az, hogy az egész folyamatot tekintsük. Sem a részleteket, sem a végcélt 
nem szabad szem elől tévesztenünk -— bár néha pontosan ez történik -, csak így készíthe- 
tünk teljes értékű programokat. 


Ez a fejezet a programfejlesztés azon részeivel foglalkozik, melyek nem vonják magukkal 
egyes kódrészek írását és javítását. A tárgyalás kevésbé pontos és részletes, mint a koráb- 
ban bemutatott nyelvi tulajdonságok és programozási eljárások tárgyalása, de nem is lehet 
olyan tökéletes , szakácskönyvet" írni, amely leírná, hogyan kell jó programot készíteni. Lé- 
tezhetnek részletes hogyan kell" leírások egyes programfajtákhoz, de az általánosabb 
alkalmazási területekhez nem. Semmi sem pótolja az intelligenciát, a tapasztalatot, és 
a programozási érzéket. Következésképpen ez a fejezet csak általános tanácsokat ad, illet- 
ve megközelítési módokat mutat be és tanulságos megfigyeléseket kínál. 


A problémák megközelítését bonyolítja a programok eleve elvont természete és az a tény, 
hogy azok a módszerek, melyek kisebb projekteknél (például amikor egy vagy két ember 
ír 10 000 sornyi kódot) működnek, nem szükségszerűen alkalmazhatók közepes vagy nagy 
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projektekben. Ezért számos kérdést inkább a kevésbé elvont mérnöki tudományokból át- 
vett hasonlatokon keresztül közelítünk meg, kódpéldák használata helyett. A programter- 
vezés tárgyalása a Ct- fogalmaival, illetve a kapcsolódó példák a 24. és 25. fejezetben ta- 
lálhatók, de az itt bemutatott elvek tükröződnek mind magában a C-t nyelvben, mind 
a könyv egyes példáiban. 


Arra is emlékeztetném az olvasót, hogy az alkalmazási területek, emberek és programfej- 
lesztő környezetek rendkívül sokfélék, ezért nem várható el, hogy minden itteni javaslatnak 
közvetlenül hasznát vehessük egy adott probléma megoldásában. A megfigyelések valós 
helyzetekben születtek és számos területen felhasználhatók, de nem tekinthetők általános 
érvényűnek, ezért nem árt némi egészséges szkepticizmus. 


A Cr úgy is tekinthető, mint egy , jobb C". De ha így teszünk, kihasználatlanul maradnak 
a C44 igazi erősségei, így a nyelv előnyeinek csak töredéke érvényesül. Ez a fejezet kimon- 
dottan azokra a tervezési megközelítésekre összpontosít, melyek lehetővé teszik a C-t el- 
vont adatábrázolási és objektumközpontú programozási lehetőségeinek hatékony haszná- 
latát. Az ilyen módszereket gyakran nevezzük objektumorientált (object-oriented) 
tervezésnek. 


A fejezet fő témái a következők: 


6 Aszoftverfejlesztés legfontosabb szempontja, hogy tisztában legyünk vele, mit 
is készítünk. 

6 A sikeres szoftverfejlesztés sokáig tart. 

6 Az általunk épített rendszerek összetettségének határait saját tudásunk és eszkö- 
zeink képességei szabják meg. 

46 Semmiféle tankönyvi módszer nem helyettesítheti az intelligenciát, a tapasztala- 
tot, a jó tervezési és programozási érzéket. 

6 A wKkísérletezés minden bonyolultabb program elkészítésénél lényeges. 

6 A programkészítés különböző szakaszai — a tervezés, a programozás és a teszte- 
lés — nem választhatók el szigorúan egymástól. 

6 A programozás és a tervezés nem választhatók el e tevékenységek megszerve- 
zésének kérdésétől. 


Könnyen abba a hibába eshetünk -— és persze megfizetjük az árát —, hogy ezeket a szem- 
pontokat alábecsüljük, pedig az elvont ötleteket nehéz a gyakorlatba áttenni. Tudomásul 
kell vennünk a tapasztalat szükségességét: éppúgy, mint a csónaképítés, a kerékpározás, 
vagy éppen a programozás, a tervezés sem olyan képesség, amely pusztán elméleti tanul- 
mányokkal elsajátítható. 
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Gyakran elfeledkezünk a rendszerépítés emberi tényezőiről, és a programfejlesztés folya- 
matát egyszerűen meghatározott lépések sorozatának tekintjük, mely ,a bemenetből adott 
műveletek végrehajtásával előállítja a kívánt kimenetet, a lefektetett szabályoknak megfele- 
lően." A programozási nyelv, amelyet használunk, elfedi az emberi tényező jelenlétét, már- 
pedig a tervezés és a programozás emberi tevékenységek -— ha erről megfeledkezünk, nem 
járhatunk sikerrel. 


Ez a fejezet olyan rendszerek tervezésével foglalkozik, melyek a rendszert építő emberek 
tapasztalatához és erőforrásaihoz képest igényesek. Úgy tűnik, a fejlesztők szeretik fesze- 
getni lehetőségeik határait. Az olyan munkáknál, melyek nem jelentenek ilyen kihívást, 
nincs szükség a tervezés megvitatására, hiszen ezeknek kidolgozott kereteik vannak, 
amelyeket nem kell széttörni. Csak akkor van szükség új, jobb eszközök és eljárások elsa- 
játítására, amikor valami igényes dologra vállalkozunk. Arra is hajlamosak vagyunk, hogy 
hozzánk képest újoncokra olyan feladatokat bízzunk, melyekről , mi tudjuk, hogyan kell el- 
végezni", de ők nem. 


Nem létezik , egyetlen helyes módszer" minden rendszer tervezésére és építésére. A hitet az 
, egyetlen helyes módszerben" gyermekbetegségnek tekinteném, ha nem fordulna elő oly 
gyakran, hogy tapasztalt programozók és tervezők engednek neki. Emlékeztetek arra, hogy 
azért, mert egy eljárás a múlt évben egy adott munkánál jól működött, még nem biztos, 
hogy ugyanaz módosítás nélkül működni fog valaki másnál vagy egy másik munka során 
is. A legfontosabb, hogy mentesek legyünk az ilyesfajta feltételezésektől. 


Az itt leírtak természetesen a nagyobb méretű programok fejlesztésére vonatkoznak. Azok, 
akik nem működnek közre ilyen fejlesztésben, visszaülhetnek és örülhetnek, látván, mi- 
lyen rémségektől menekültek meg, illetve nézegethetik az egyéni munkával foglalkozó ré- 
szeket. A programok méretének nincs alsó határa, ahol a kódolás előtti tervezés még 
ésszerű, de létezik ilyen határ, amennyiben a tervezés és dokumentálás megközelítési 
módjáról van szó. A célok és a méret közötti egyensúly fenntartásának kérdéseivel 
a §23.5.2 pont foglalkozik. 


A programfejlesztés központi problémája a bonyolultság. A bonyolultsággal pedig egyetlen 
módon lehet elbánni, az ,oszd meg és uralkodj! elvet követve. Ha egy problémát két ön- 
magában kezelhető részproblémára választhatunk szét, félig máris megoldottuk azt. Ez az 
egyszerű elv bámulatosan változatos módokon alkalmazható. Nevezetesen, egy modul 
vagy egy osztály használata a rendszer megtervezésénél két részre osztja a progra- 
mot -— a tényleges megvalósításra és a felhasználói kódra — amelyeket ideális esetben csak 
egy jól definiált felület (interface) kapcsol össze: ez a programmal járó bonyolultság keze- 
lésének alapvető megközelítése. Ugyanígy a programtervezési folyamat is külön tevékeny- 
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ségekre bontható, s így a közreműködő és egymással kapcsolatban álló fejlesztők között 
feladatokra bontva szétosztható: ez pedig a fejlesztési folyamat és a résztvevő programozók 
közötti bonyolult kapcsolatok kezelésének alapvető megközelítése. 


Mindkét esetben a felosztás és a kapcsolatot megteremtő felületek meghatározása az, ahol 
a legnagyobb tapasztalatra és érzékre van szükség. Ez nem egyszerű, mechanikusan meg- 
oldható feladat; jellemzően éleslátást igényel, melyre csak egy rendszer alapos tanulmányo- 
Zása és az elvonatkoztatási szintek megfelelő megértése által tehetünk szert (lásd: 423.4.2, 
§24.3.1 és §25.39. Ha egy programot vagy fejlesztési folyamatot csak bizonyos szemszögből 
vizsgálunk, súlyos hibákat véthetünk. Azt is vegyük észre, hogy különválasztani mind az 
emberek feladatait, mind a programokat könnyű. A feladat nehéz része a hatékony kapcso- 
lattartás biztosítása a válaszfal két oldalán levő felek között anélkül, hogy lerombolnánk 
a válaszfalat vagy elnyomnánk az együttműködéshez szükséges kommunikációt. 


Ez a fejezet egy tervezési megközelítést mutat be, nem egy teljes tervezési módszert; annak 
bemutatása túlmutatna e könyv keretein. Az itt bemutatott megközelítés az általánosí- 
tás — vagyis a formális megfogalmazás — különböző fokozataival és a mögöttük megbúvó 
alapvető elvekkel ismertet meg. Nem szakirodalmi áttekintés és nem szándékszik érinteni 
minden, a szoftverfejlesztésre vonatkozó témát, vagy bemutatni minden szempontot. Ez is- 
mét csak meghaladná e könyv lehetőségeit. Ilyen áttekintést találhatunk ÍBooch,1994l-ben. 
Feltűnhet, hogy a kifejezéseket itt elég általános és hagyományos módon használom. 
A , legérdekesebbeknek" — tervezés, prototípus, programozó — a szakirodalomban számos 
különböző és gyakran egymással ellentétes definíciója található. Legyünk óvatosak, nehogy 
olyan nem szándékolt jelentést olvassunk ki az itt elmondottakból, melyek az egyes kifeje- 
zések önmagában vett vagy csupán , helyileg" pontos meghatározásain alapulnak. 


23.3. Célok és eszközök 


A professzionális programozás célja olyan terméket létrehozni, mellyel felhasználói elége- 
dettek lesznek. Ennek elsődleges módja olyan programot alkotni, melynek belső felépítése 
tiszta, és csapatot kovácsolni olyan tervezőkből és programozókból, akik elég ügyesek és 
lelkesek ahhoz, hogy gyorsan és hatékonyan reagáljanak a változásokra és élni tudjanak le- 
hetőségeikkel. 
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Miért? A program belső szerkezete és keletkezésének folyamata ideális esetben nem érinti 
a végfelhasználót. Nyíltabban fogalmazva: ha a végfelhasználónak aggálya van, hogyan ír- 
ták meg a programot, akkor azzal a programmal valami baj van. Ezt figyelembe véve felte- 
hetjük a kérdést: miben áll a program szerkezetének és a programot megalkotó emberek- 
nek a fontossága? 


Először is, egy programnak tiszta belső felépítéssel kell rendelkeznie, hogy megkönnyítse 


a tesztelést, 

a más rendszerekre való átültetést, 

a program karbantartását és módosítását, 
a bővítést, 

az újraszervezést és 

a kód megértését. 


p ...... 


A lényeg, hogy egyetlen sikeres nagy program története sem ér véget a piacra kerüléssel; 
újabb és újabb programozók és tervezők dolgoznak rajta, új hardverre viszik át, előre nem 
látott célokra használják fel és többször is átalakítják szerkezetét. A program élete folyamán 
új változatokat kell készíteni, elfogadható mennyiségű hibával, elfogadható idő alatt. Ha ez- 
zel nem számolunk, kudarcra vagyunk ítélve. 


Vegyük észre, hogy bár a végfelhasználók ideális esetben nem kell, hogy ismerjék egy rend- 
szer belső felépítését, előfordulhat, hogy kíváncsiak rá, például azért, hogy fel tudják be- 
csülni megbízhatóságát, lehetséges felülvizsgálatát és bővítését. Ha a kérdéses program 
nem egy teljes rendszer, csak más programok építését segítő könyvtárak készlete, a felhasz- 
nálók még több részletet akarnak tudni, hogy képesek legyenek jobban kihasználni 


a könyvtárakat és ötleteket meríthessenek belőlük. 


Egyensúlyt kell teremteni a program átfogó tervezésének mellőzése és a szerkezetre fekte- 
tett túlzott hangsúly között. Az előbbi vég nélküli javítgatásokhoz vezet (, ezt most leszállít- 
juk, a problémát meg majd kijavítjuk a következő kiadásban"), az utóbbi túlbonyolítja 
a tervezést és a lényeg elvész a formai tökéletességre való törekvés közben, ami azt ered- 
ményezi, hogy a tényleges megvalósítás késedelmet szenved a program szerkezetének 
folytonos alakítgatása miatt ( de ez az új felépítés sokkal jobb, mint a régi; az emberek 
hajlandóak várni rá"). A forma tartalom fölé rendelése gyakran eredményez olyan erőfor- 
rás-igényű rendszereket is, melyeket a leendő felhasználók többsége nem engedhet meg 
magának. Az egyensúly megtartása a tervezés legnehezebb része és ez az a terület, ahol 
a tehetség és a tapasztalat megmutatkozik. A választás az önálló programozó számára is ne- 
héz, de még nehezebb a nagyobb programoknál, melyek több, különböző képességű em- 
ber munkáját igénylik. 
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A programot egy olyan szervezett közösségnek kell megalkotnia és fenntartania, mely 
a személyi és vezetési változások ellenére képes a feladatot megoldani. Népszerű megkö- 
zelítés a programfejlesztést néhány viszonylag alacsony szintű feladatra szűkíteni, melyek 
egy merev vázba illeszkednek. Az elgondolás egy könnyen betanítható (olcsó) és , cserél- 
hető", alacsony szintű programozókból ( kódolókból") álló osztály és egy valamivel kevés- 
bé olcsó, de ugyanúgy cserélhető (és ugyanúgy mellőzhető) tervezőkből álló osztály 
létrehozása. A kódolókról nem tételezzük fel, hogy tervezési döntéseket hoznak, míg a ter- 
vezőkről nem tételezzük fel, hogy a kódolás , piszkos" részleteivel törődnek. Ez a megkö- 
zelítés gyakran csődöt mond; ahol pedig működik, nagy méretű, de gyenge teljesítményű 
programokat eredményez. 


E megoldás buktatói a következők: 


6 Elégtelen kapcsolattartás a megvalósítást végzők és a tervezők között, ami alkal- 
mak elmulasztását, késést, rossz hatékonyságot, és a tapasztalatból való tanulás 
képtelensége miatt ismétlődő problémákat eredményez. 

6 A programozók kezdeményezési hatáskörének elégtelensége, ami a szakmai fej- 
lődés hiányához, felületességhez és káoszhoz vezet. 

E rendszer alapvető gondja a visszajelzés hiánya, mely lehetővé tenné, hogy a közreműkö- 
dők egymás tapasztalataiból tanuljanak. Ez a szűkös emberi tehetség elvesztegetése. 
Az olyan keretek biztosítása, melyen belül mindenki megcsillanthatja tehetségét, új képes- 
ségeket fejleszthet ki, ötletekkel járulhat hozzá a sikerhez és jól érezheti magát, nemcsak az 
egyedüli tisztességes megoldás, hanem gyakorlati és gazdasági értelme is van. 


Másrészt egy rendszert nem lehet felépíteni, dokumentálni és a végtelenségig fenntartani 
valamilyen áttekinthető szerkezet nélkül. Egy újításokat is igénylő munka elején gyakran az 
a legjobb, ha egyszerűen megkeressük a legjobb szakembereket és hagyjuk őket, hogy úgy 
közelítsék meg a problémát, ahogy a legjobbnak tartják. A munka előrehaladtával azonban 
egyre inkább ügyelni kell a helyes ütemezésre, a részfeladatok kiosztására, a bevont sze- 
mélyek közötti kapcsolattartásra és bizonyos — a jelölésre, elnevezésekre, dokumentációra, 
tesztelésre stb. vonatkozó - irányelvek betartására. Ismét csak egyensúlyra és a helyénvaló 
iránti érzékre van szükség. Egy túl merev rendszer akadályozhatja a fejlődést és elfojthatja 
az innovációt. Ebben az esetben a vezető tehetsége és tapasztaltsága mérettetik meg, de az 
önálló programozó számára is ugyanilyen dilemma kiválasztani, hol próbáljon ügyeskedni 
és hol csinálja ,a könyv szerint". 


Az adott munkánál ajánlatos nem csak a következő kiadásra, hanem hosszú távra tervezni. 
Az előrelátás hiánya mindig megbosszulja magát. A szervezeti felépítést és a programfej- 
lesztési stratégiát úgy kell megválasztani, hogy több program több kiadásának megalkotá- 
sát célozzuk meg - vagyis sikerek sorozatát kell megterveznünk. 
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A , tervezés" célja a program számára tiszta és viszonylag egyszerű belső szerkezet — archi- 
tektűra — létrehozása. Más szóval, olyan vázat akarunk alkotni, melybe beilleszthetők az 
egyes kódrészek és ezáltal irányelvként szolgál e kódrészek megírásához. 


A terv a tervezési folyamat végterméke (amennyiben egy körkörös folyamatnak végtermé- 
ke leheD. Ez áll a tervező és a programozó, illetve az egyes programozók közti kapcsolat- 
tartás középpontjában. Fontos, hogy itt kellő arányérzékünk legyen. Ha én — mint önálló 
programozó - egy kis programot tervezek, melyet holnap fogok elkészíteni, megfelelő pon- 
tosságú és részletességű lehet egy boríték hátára firkált pár sor. A másik véglet: egy terve- 
zők és programozók százait foglalkoztató rendszer fejlesztése könyveket kitevő, gondosan 
megírt , szabványokat" kívánhat, valamilyen szabályhoz részben vagy teljes egészében iga- 
zodó jelölések használatával. Egy terv megfelelő részletességi, pontossági és formalitási 
szintjének meghatározása önmagában véve is kihívó szakmai és vezetési feladat. 


Ebben és a következő fejezetekben feltételezem, hogy egy program terve osztálydeklaráci- 
ók egy halmazával (a privát deklarációikat, mint zavaró részleteket, általában elhagyom) és 
a köztük levő kapcsolatokkal van kifejezve. Ez persze egyszerűsítés: egy konkrét tervben 
sok más kérdés is felmerül; például a párhuzamos folyamatok, a névterek kezelése, a nem 
tag függvények és adatok használata, az osztályok és függvények paraméterezése, az újra- 
fordítás szükségességét a lehető legalacsonyabb szintre visszaszorító kódszervezés, a 
perzisztencia és a több-számítógépes használat. A tárgyalásnak ezen a szintjén mindenkép- 
pen szükség van egyszetűsítésre és a C4--ban a tervezéshez az osztályok megfelelő kiin- 
dulópontot jelenthetnek. A fent említett témakörök közül néhányat futólag ez a fejezet is 
érint, de a Ct4-ban való tervezésre közvetlenül hatást gyakorlókat a 24. és 25. fejezet tár- 
gyalja. Ha egy bizonyos objektumorientált tervezési modellre részleteiben vagyunk kíván- 
csiak, [Booch, 1994] lehet segítségünkre. 


Az elemzés (analízis, analysis) és a tervezés (design) közötti különbségre nem térek ki kü- 
lönösebben, egyrészt mert nem témája e könyvnek, másrészt az egyes tervezési módszerek 
esetében e különbséget más-más módon határozhatnánk meg. Röviden annyit mondha- 
tunk, hogy az elemzési módszert mindig az adott tervezési megközelítéshez kell igazítani, 
azt pedig a használt programozási nyelv és stílus alapján kell megválasztani. 
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23.4. A fejlesztési folyamat 


A szoftverfejlesztés ismétlést és gyarapodást jelent: a folyamat minden szakasza a fejlesztés 
alatt újra és újra felülvizsgálatra kerül és minden egyes felülvizsgálat finomítja az adott sza- 
kasz végtermékét. A fejlesztési folyamatnak általában nincs kezdete és nincs vége. Amikor 
egy programrendszert megtervezünk és elkészítünk, más emberek terveit, könyvtárait és 
programjait vesszük alapul. Amikor befejezzük, a terv és a kód törzsét másokra hagyjuk, 
hogy finomítsák, felülvizsgálják, bővítsék és más gépekre áttegyék azt. Természetesen egy 
adott munkának lehet meghatározott kezdete és vége, és fontos is (bár gyakran meglepő- 
en nehéz), hogy azt időben és térben tisztán és pontosan behatároljuk. Ha azonban úgy te- 
szünk, mintha tiszta lappal indulnánk, komoly problémákat okozhatunk. Úgy tenni, mint- 
ha a világ a program , végső átadásánál" végződne, egyaránt fejfájást okozhat utódaink és 
gyakran saját magunk számára. 


Ebből következik, hogy a következő fejezetek bármilyen sorrendben olvashatók, mivel egy 
valós munka során a tervezési és megvalósítási szempontok majdnem tetszés szerint átfed- 
hetik egymást. Ez azt jelenti, hogy a ,tervezés" majdnem mindig újratervezés, amely egy 
előző tervezésen és némi fejlesztési tapasztalaton alapul. Továbbá, a tervezést korlátozzák 
az ütemtervek, a résztvevő emberek képességei, a kompatibilitási kérdések és így tovább. 
A tervező, vezető vagy programozó számára nagy kihívást jelent rendet teremteni e folya- 
matban anélkül, hogy elfojtanánk az újítási törekvéseket és tönkretennénk a visszajelzés 


rendszerét, melyek a sikeres fejlesztéshez szükségesek. 
A fejlesztési folyamat három szakaszból áll: 


6 Elemzés: a megoldandó probléma kiterjedésének meghatározása 
6 Tervezés: a rendszer átfogó felépítésének megalkotása 
46 Megvalósítás: a kód megírása és ellenőrzése 


Még egyszer emlékeztetnék e folyamat ismétlődő természetére — nem véletlen, hogy a sza- 
kaszok között nem állítottam fel sorrendet. Vegyük észre azt is, hogy a programfejlesztés 
néhány fő szempontja nem külön szakaszként jelentkezik, mivel ezeknek a folyamat során 
mindvégig érvényesülniük kell: 


Kísérletezés 

Ellenőrzés 

A tervek és a megvalósítás elemzése 
Dokumentálás 

Vezetés 


......... 
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A program fenntartása vagy , karbantartása" egyszerűen e fejlesztési folyamat többszöri is- 
métlését jelenti (§23.4.69. 


A legfontosabb, hogy az elemzés, a tervezés és a megvalósítás ne váljon el túlzottan egymás- 
tól, és hogy a bevont emberek közös szellemiség, kultúra és nyelv révén hatékonyan tudja- 
nak egymással kommunikálni. Nagyobb programok fejlesztésénél ez sajnos ritkán van így. 
Ideális esetben az egyének a munka során több szakaszban is részt vesznek; ez az ismeretek 
és tapasztalatok átadásának legjobb módja. Sajnos a programfejlesztő cégek gyakran akadá- 
lyozzák az ilyen mozgást, például azáltal, hogy a tervezőknek magasabb beosztást és/vagy 
magasabb fizetést adnak, mint a ,csak programozóknak". Ha gyakorlati szempontból nem 
célszerű, hogy a munkatársak vándorolva tanuljanak és tanítsanak, legalább arra biztassuk 
őket, hogy rendszeresen beszélgessenek a fejlesztés ,más szakaszaiba" bevontakkal. 


Kisebb és közepes projekteknél gyakran nem különböztetik meg az elemzést és a tervezést; 
e két szakasz egyesül. A kis programok készítésénél általában ugyanígy nem válik szét a ter- 
vezés és a programozás, ami persze megoldja a kommunikációs problémákat. Fontos, hogy 
a formalitások és a szakaszok elkülönítése mindig az adott munkához igazodjanak 
(423.5.29; nem létezik egyetlen, örök érvényű út. 


Az itt leírt programfejlesztési modell gyökeresen különbözik a hagyományos , vízesés" mo- 
delltől, amelyben a fejlesztés szabályosan és egyenes irányban halad a fejlesztési szakaszo- 
kon át, az elemzéstől a tesztelésig. A vízesés modell alapvető baja, hogy az információ 
folyása egyirányú. Ha a , folyás irányában haladva" problémákba ütközünk, a szervezeti fel- 
építés és amunkamódszerek arra kényszerítenek, hogy helyben oldjuk meg azokat, az elő- 
ző szakaszokra való hatás nélkül. A visszacsatolás ezen hiánya gyenge tervekhez vezet, 
a helyi javítások pedig torz megvalósítást eredményeznek. Vannak elkerülhetetlen esetek, 
amikor az információ mindenképpen visszafelé áramlik és megváltoztatja az eredeti terve- 
ket. A gerjesztett , hullám" csak lassan és nehézkesen jut el céljához, hiszen a rendszert úgy 
alkották meg, hogy ne legyen szükség változtatásokra és a rendszer emiatt lassan és kellet- 
elve tehát olyan elvvé változik, 
mely szerint egy részleg nem adhat többletmunkát más részlegeknek , a saját kényelme ér- 


A e? 


lenül reagál. A ,semmi változtatás" vagy a , helyi javítás 


dekében". Lehetséges, hogy mire egy nagyobb hibát észlelnek, már olyan sok papírmunkát 
végeztek, hogy a kód javításához szükséges erőfeszítés eltörpül ahhoz képest, ami a doku- 
mentáció módosításához kell. Ilyenkor a papírmunka válik a programfejlesztés fő kerékkö- 
tőjévé. Természetesen ilyen problémák előfordulhatnak és elő is fordulnak, jóllehet a nagy 
rendszerek fejlesztését alaposan megszervezik. Mindenképpen elengedhetetlen némi pa- 
pírmunka. Az egyenes vonalú (vízesés) fejlesztési modell alkalmazása azonban nagyban 
növeli a valószínűségét, hogy a probléma kezelhetetlenné válik. 
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A vízeséses modellel az a probléma, hogy nincs benne megfelelő visszacsatolás és képte- 
len a változásokra reagálni. Az itt vázolt ciklikus megközelítés veszélye viszont a kísértés, 
hogy a valódi gondolkodás és haladás helyett nem azonos cél érdekében végrehajtott mó- 
dosítások sorát végezzük el. Mindkét problémát könnyebb felismerni, mint megoldani, és 
bármilyen jól is szervezzük meg a feladat végrehajtását, könnyen összetéveszthetjük a pusz- 
ta munkát a haladással. Természetesen a munka előrehaladtával a fejlesztési folyamat kü- 
lönböző szakaszainak jelentősége változik. Kezdetben a hangsúly az elemzésen és a terve- 
zésen van, és kevesebb figyelmet fordítunk a programozási kérdésekre. Ahogy múlik az 
idő, az erőforrások a tervezés és a programozás felé tolódnak, majd inkább a programozás 
és a tesztelés felé. Kulcsfontosságú azonban, hogy soha ne összpontosítsunk csupán az 
elemzés/tervezés/megvalósítás egyikére, kizárva látókörünkből a többit. 


Ne felejtsük el, hogy nem segíthet rajtunk semmilyen, ,a részletekre is kiterjedő" figyelem, 
vezetési módszer vagy fejlett technológia, ha nincs tiszta elképzelésünk arról, mit is aka- 
runk elérni. Több terv hiúsul meg amiatt, hogy nincsenek jól meghatározott és valószerű 
céljai, mint bármilyen más okból. Bármit teszünk is és bárhogyan fogunk is hozzá, tűzzünk 
ki kézzelfogható célokat, jelöljük ki a hozzá vezető út állomásait, és használjunk fel minden 
megfelelő technológiát, ami csak elérhető — még akkor is, ha az beruházást igényel —, mert 
az emberek jobban dolgoznak megfelelő eszközökkel és megfelelő környezetben. Ne 
higgyük persze, hogy könnyű ezt a tanácsot megfogadni. 


23.4.1. A fejlesztés körforgása 


Egy program fejlesztése során állandó felülvizsgálatra van szükség. A fő ciklus a következő 
lépések ismételt végrehajtásából áll: 


1. Vizsgáljuk meg a problémát. 

2. Alkossunk átfogó tervet. 

3. Keressünk szabványos összetevőket. 
e Igazítsuk ezeket a tervhez. 

4. Készítsünk új szabványos összetevőket. 
e Igazítsuk ezeket is a tervhez. 

5. Állítsuk össze a konkrét tervet. 


Hasonlatként vegyünk egy autógyárat. A projekt beindításához kell, hogy legyen egy átfo- 
gó terv az új autótípusról. Az előzetes tervnek valamilyen elemzésen kell alapulnia és álta- 
lánosságban kell leírnia az autót, inkább annak szándékolt használatát, mintsem a kívánt 
tulajdonságok kialakításának részleteit szem előtt tartva. Eldönteni, mik is a kívánt tulajdon- 
ságok — vagy még inkább, a döntéshez viszonylag egyszerű irányelveket adni — gyakran 
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a munka legnehezebb része. Ezt sikeresen általában egyetlen, nagy áttekintéssel rendelke- 
ző egyén tudja elvégezni, és ez az, amit gyakran látomásnak (vision) nevezünk. Igen gya- 
kori, hogy hiányoznak az ilyen tiszta célok — márpedig a terv ezek nélkül meginoghat vagy 
meg is hiúsulhat. 


Tegyük fel, hogy egy közepes nagyságú autót akarunk építeni, négy ajtóval és erős motor- 
ral. A tervezés első szakasza a leghatározottabban nem az autó Cés az alkatrészek) megter- 
vezése a ,semmiből". Egy meggondolatlan programtervező vagy programozó hasonló kö- 
rülmények között (ostobán) pontosan ezt próbálná tenni. 


Az első lépés annak számbavétele, milyen alkatrészek szerezhetők be a gyár saját készlete- 
iből és megbízható szállítóktól. Az így talált alkatrészek nem kell, hogy pontosan illeszked- 
jenek az új autóba. Lesz mód az alkatrészek hozzáigazítására. Azt is megtehetjük, hogy az 
ilyen alkatrészek , következő kiadásához" irányelveket adunk, hogy saját elképzeléseink- 
hez jobban illeszkedjenek. Például létezhet egy motor, melynek megfelelőek a tulajdonsá- 
gai, azzal a kivétellel, hogy kicsit gyengébb a leadott teljesítménye. A cég vagy a motor szál- 
lítója rászerelhet egy turbófeltöltőt, hogy ezt helyrehozza, anélkül, hogy befolyásolná az 
alapvető terveket. Vegyük észre, hogy az ilyen, ,az alaptervet nem befolyásoló" változtatás 
valószínűsége kicsi, hacsak az eredeti terv nem előlegezi meg valamilyen formában az iga- 
zíthatóságot. Az ilyen igazíthatóság általában együttműködést kíván köztünk és a motor 
szállítója között. A programozó hasonló lehetőségekkel rendelkezik: a többalakú (poli- 
morf) osztályok és sablonok (template) például hatékonyan felhasználhatók egyedi válto- 
zatok készítésére. Nem szabad azonban elvárnunk, hogy az osztály készítője a mi szájunk 


íze szerint bővítse alkotását; ehhez a készítő előrelátására vagy a velünk való együttműkö- 
désre van szükség. 


Ha kimerült a megfelelő szabványos alkatrészek választéka, az autótervező nem rohan, 
hogy megtervezze az új autóhoz az optimális új alkatrészeket. Ez egyszerűen túl költséges 
lenne. Tegyük fel, hogy nem kapható megfelelő légkondicionáló egység és hogy egy meg- 
felelő L alakú tér áll rendelkezésre a motortéren belül. Az egyik megoldás egy L alakú lég- 
kondicionáló egység megtervezése lenne, de annak valószínűsége, hogy ez a különleges 
forma más autótípusoknál is használható, még alapos igazítás esetén is csekély. Ebből kö- 
vetkezik, hogy autótervezőnk nem lesz képes az ilyen egységek termelési költségeit más 
autótípusok tervezőivel megosztani, így az egység kihasználható élettartama rövid lesz. Ér- 
demes tehát olyan egységet tervezni, mely szélesebb körben számíthat érdeklődésre; vagyis 
egy tisztább vonalú egységet kell tervezni, mely jobban az igényekhez igazítható, mint a mi 
elméletben elkészített L alakú furcsaságunk. Ez valószínűleg több munkával jár, mint az L 
alakú egység és magával vonhatja az autó átfogó terveinek módosítását is, hogy illeszked- 
jen az általánosabb célú egységhez. Mivel az új egység szélesebb körben használható, mint 
a mi L alakú csodánk, feltételezhető, hogy szükség lesz egy kis igazításra, hogy tökéletesen 
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illeszkedjen a mi felülvizsgált igényeinkhez. A programozó ismét hasonló lehetőségek kö- 
zül választhat: ahelyett, hogy az adott programra nézve egyedi kódot írna, új, általánosabb 
összetevőt tervezhet, amely remélhetőleg valamilyen szabvánnyá válik. 


Amikor végképp kifogytunk a lehetséges szabványos összetevőkből, összeállítjuk a , végle- 
ges" tervet. A lehető legkevesebb egyedi tervezésű alkatrészt használjuk, mert jövőre — kis- 
sé más formában - ismét végig kell csinálnunk ugyanezt a munkát a következő új modell- 
hez, és az egyedi alkatrészek lesznek azok, amelyeket a legvalószínűbb, hogy újra kell 
építenünk vagy el kell dobnunk. Sajnos a hagyományosan tervezett programokkal kapcso- 
latban az a tapasztalat, hogy kevés bennük az olyan rész, amelyet egyáltalán önálló össze- 
tevőnek lehetne tekinteni és az adott programon kívül máshol is fel lehetne használni. 


Nem állítom, hogy minden autótervező olyan ésszerűen gondolkodik, mint ahogy a hason- 
latban felvázoltam vagy hogy minden programtervező elköveti az említett hibákat. Éppen 
ellenkezőleg, a bemutatott modell a programtervezésben is használható. Ez a fejezet és 
a következők olyan eljárásokat ismertetnek, melyek a C---ban működnek. A programok 
nem kézzelfogható természete miatt viszont a hibákat kétségtelenül nehezebb elkerülni 
(424.3.1, 24.3.4), és rámutatok majd arra is (423.5.3.1), hogy a cégek működési elve gyakran 
elveszi az emberek bátorságát, hogy az itt vázolt modellt használják. Ez a fejlesztési modell 
valójában csak akkor működik jól, ha hosszabb távra tervezünk. Ha látókörünk csak a kö- 
vetkező kiadásig terjed, a szabványos összetevők megalkotása és fenntartása értelmetlen, 
egyszerűen felesleges túlmunkának fogjuk látni. E modell követése olyan fejlesztőközössé- 
gek számára javasolt, melyek élete számos projektet fog át és melyek mérete miatt érdemes 
pénzt fektetni a szükséges eszközökbe (a tervezéshez, programozáshoz és projektvezetés- 
hez) és oktatásba (a tervezők, programozók és vezetők részére). Modellünk valójában egy- 
fajta ,szoftvergyár" vázlata, amely furcsa módon csak méreteiben különbözik a legjobb 
önálló programozók gyakorlatától, akik az évek során módszerek, tervek, eszközök és 
könyvtárak készletét építették fel, hogy fokozzák személyes hatékonyságukat. Sajnos úgy 
tűnik, a legtöbb cég elmulasztotta kihasználni a legjobbak gyakorlati tudását, mert hiány- 
zott belőle az előrelátás és a képesség, hogy az általuk használt megközelítést nagyobb 
programokra is alkalmazza. 


Vegyük észre, hogy nincs értelme minden , szabványos összetevőtől" elvárni, hogy általá- 
nos érvényű szabvány legyen. Nemzetközileg szabványos könyvtárból csak néhány marad- 
hat fenn. A legtöbb összetevő vagy alkatrész (csak) egy országon, egy iparágon, egy 
gyártósoron, egy osztályon, egy alkalmazási területen stb. belül lesz szabvány. A világ egy- 
szerűen túl nagy ahhoz, hogy valóságos vagy igazán kívánatos cél legyen minden eszköz- 
re egyetemes szabványt alkotni. 
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Ha már az elején az egyetemességet tűzzük ki célul, a tervet arra ítéljük, hogy soha ne le- 
gyen befejezve. Ennek egyik oka, hogy a fejlesztés körkörös folyamat, és elengedhetetlen, 
hogy legyen egy működő rendszere, amelyből tapasztalatokat meríthetünk (423.4.3.69. 


23.4.2. Tervezési célok 


Melyek a tervezés átfogó céljai? Az egyik természetesen az egyszerűség, de milyen szem- 
pontok szerint? Feltételezzük, hogy a tervnek fejlődnie kell, vagyis a programot majd bőví- 
teni, más rendszerre átvinni, finomhangolni és többféle, előre nem látható módon módosí- 
tani lesz szükséges. Következésképpen olyan tervet és rendszert kell megcéloznunk, amely 
egyszerű, de könnyen és sokféle módon módosítható. A valóságban a rendszerrel szemben 
támasztott követelmények már a kezdeti terv és a program első kibocsátása között többször 
megváltoznak. 


Ez magával vonja, hogy a programot úgy kell megtervezni, hogy a módosítások sorozata 
alatt a lehető legegyszerűbb maradjon. A módosíthatóságot figyelembe véve a következő- 
ket kell célul kitűznünk: 


$ Rugalmasság 


4 Bővíthetőség 
4 Hordozhatóság (más rendszerekre való átültethetőség) 


A legjobb, ha megpróbáljuk elszigetelni a program azon területeit, melyek valószínűleg vál- 


tozni fognak, a felhasználók számára pedig lehetővé tesszük, hogy módosításaikat e részek 
érintése nélkül végezhessék el. 


Ezt a program kulcsfogalmainak azonosításával és azzal érhetjük el, hogy minden egyes 
osztályra kizárólagos felelősséggel rábízzuk egy fogalommal kapcsolatos minden informá- 
ció kezelését. Ez esetben mindennemű változtatás csupán az adott osztály módosításával 
érhető el. Ideális esetben egy fogalom módosításához elég egy új osztály származtatása 


(423.4.3.5) vagy egy sablon eltérő paraméterezése. Természetesen az elvet a gyakorlatban 
sokkal nehezebb követni. 


Vegyünk egy példát: egy meteorológiai jelenségeket utánzó programban egy esőfelhőt 
akarunk megjeleníteni. Hogyan csináljuk? Nem lehet általános eljárásunk a felhő megjele- 


nítésére, mivel a felhő kinézete függ a felhő belső állapotától és ez az állapot a felhő kizá- 
rólagos , felelőssége" alá kell, hogy tartozzon. 
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A probléma első megoldása, hogy hagyjuk a felhőre a saját megjelenítését. Ez bizonyos kö- 
rülmények között elfogadható, de nem általános megoldás, mert egy felhőt sokféle módon 
lehet megjeleníteni: részletes képpel, elnagyolt vázlatként, vagy mint egy jelet egy térképen. 
Más szóval az, hogy egy felhő mire hasonlít, függ mind a felhőtől, mind a környezetétől. 


A másik megoldás, hogy a felhőt , tájékoztatjuk" környezetéről, majd hagyjuk, hogy megje- 
lenítse magát. Ez még több esetben elfogadható, de még mindig nem általános módszer. Ha 
tudatjuk a felhővel környezetének részleteit, megsértjük azt a szabályt, hogy egy osztály 
csak egy dologért lehet felelős és hogy minden , dolog" valamelyik osztály felelőssége. Nem 
biztos, hogy eljuthatunk , a felhő környezetének" egy következetes jelöléséhez, mert általá- 
ban az, hogy egy felhő mihez hasonlít, függ mind a felhőtől, mind a nézőtől. Az, hogy szá- 
momra mihez hasonlít egy felhő, még a valós életben is meglehetősen függ attól, hogyan 
nézem: puszta szemmel, polárszűrőn keresztül vagy meteorológiai radarral. A nézőn és 
a felhőn kívül lehet, hogy valamilyen , általános hátteret" is figyelembe kell venni, például 
a nap viszonylagos helyzetét. Tovább bonyolítja a dolgot, ha egyéb objektumokat is — más 
felhőket, repülőgépeket — számításba veszünk. Hogy a tervező életét igazán megnehezít- 
sük, adjuk hozzá azt a lehetőséget is, hogy egyszerre több nézőnk van. 


A harmadik megoldás, hogy hagyjuk a felhőt és a többi objektumot (a repülőgépeket és 
a napot), hogy leírják magukat a nézőknek. E megoldás elég általános ahhoz, hogy a leg- 
több célnak megfeleljen, de jelentős árat fizethetünk érte, mert a program túlságosan bo- 
nyolult és lassú lehet. Hogyan értetjük meg például a nézővel a felhők és más objektumok 
által készített leírásokat? 

A programokban nem sűrűn fordulnak elő esőfelhők (bár a példa kedvéért lásd §15.2), de 
a különböző [/O műveletekbe szükségszerűen bevont objektumok is hasonlóan viselked- 
nek. Ez teszi a felhő példát találóvá a programok és különösen a könyvtárak tervezésére 
nézve. Logikailag hasonló példa Ct- kódját mutattam be az adatfolyamok be- és kimeneti 
rendszerének tárgyalásakor, a formázott kimenetre használt módosítóknál (manipulator, 
§21.4.6, §21.4.6.3). Le kell azonban szögeznünk, hogy a harmadik megoldás nem , a helyes", 
csupán a legáltalánosabb megoldás. A tervezőnek mérlegelnie kell a rendszer különböző 
szükségleteit, hogy megválassza az adott problémához az adott rendszerben megfelelő 
mértékű általánosságot és elvont ábrázolásmódot. Alapszabály, hogy egy hosszú életűnek 
tervezett programban az elvonatkoztatási szintnek a még megérthető és megengedhető leg- 
általánosabbnak, nem az abszolút legáltalánosabbnak kell lennie. Ha az általánosítás túlha- 
ladja az adott program kereteit és a készítők tapasztalatát, káros lehet, mert késedelmet, el- 
fogadhatatlanul rossz hatékonyságot, kezelhetetlen terveket és nyilvánvaló kudarcot von 
maga után. 
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Az ilyen módszerek kezelhetővé és gazdaságossá tételéhez az újrahasznosítás mikéntjét is 
meg kell terveznünk (423.5.1) és nem szabad teljesen elfeledkezni a hatékonyságról 


(423.4.7). 


23.4.3. Tervezési lépések 


Vegyük azt az esetet, amikor egyetlen osztályt tervezünk. Ez általában nem jó ötlet. Fogal- 
mak nem léteznek elszigetelten; más fogalmakkal való összefüggéseik határozzák meg azo- 
kat. Ugyanez érvényes az osztályokra is; meghatározásuk logikailag kapcsolódó osztályok 
meghatározásával együtt történik. Jellemzően egymással kapcsolatban lévő osztályok egy 
halmazán dolgozunk. Az ilyen halmazt gyakran osztálykönyvtárnak Cclass library) vagy 
összetevőnek (komponens, component) nevezzük. Néha az adott összetevőben lévő összes 
osztály egyetlen osztályhierarchiát alkot, néha egyetlen névtér tagjai, néha viszont csupán 


deklarációk ad hoc gyűjteményét képezik (424.4. 


Az egy összetevőben lévő osztályok halmazát logikai kötelékek egyesítik; közös stílusuk 
van vagy azonos szolgáltatásokra támaszkodnak. Az összetevő tehát a tervezés, a doku- 
mentáció, a tulajdonlás és az újrafelhasználás egysége. Ez nem jelenti azt, hogy ha valaki- 
nek egy összetevőből csak egy osztályra van szüksége, értenie és használnia kell az össze- 
tevő minden osztályát vagy be kell töltenie a programjába az összes osztály kódját. Éppen 
ellenkezőleg, általában arra törekszünk, hogy az osztályoknak a lehető legkevesebb gépi és 
emberi erőforrásra legyen szükségük. Ahhoz azonban, hogy egy összetevő bármely részét 
használhassuk, értenünk kell az összetevőt összetartó és meghatározó logikai kapcsolato- 
kat, (a dokumentációban ezek remélhetőleg eléggé világosak), a felépítésében és doku- 
mentációjában megtestesült elveket és stílust, illetve a közös szolgáltatásokat (ha vannak). 


Lássuk tehát, hogyan tervezhetünk meg egy összetevőt. Mivel ez általában komoly kihívást 
jelent, megéri lépésekre bontani, hogy könnyebb legyen a különböző részfeladatokra össz- 
pontosítani. Szokott módon, az összetevők megtervezésének sincs egyetlen helyes útja. Itt 
csupán egy olyan lépéssorozatot mutatok be, amely egyesek számára már bevált: 


1. Keressük meg a fogalmakat/osztályokat és legalapvetőbb kapcsolataikat. 
2. Finomítsuk az osztályokat a rajtuk végezhető műveletek meghatározásával. 
e  Osztályozzuk a műveleteket. Különösen figyeljünk a létrehozás, a másolás 
és a megsemmisítés szükségességére. 
e  Törekedjünk a minél kisebb méretre, a teljességre és a kényelemre. 
3. Finomítsuk az osztályokat az összefüggések meghatározásával. 
e Ügyeljünk a paraméterezésre és az öröklésre, és használjuk ki 
a függőségeket. 
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4. Határozzuk meg a felületeket. 
e Válasszuk szét a függvényeket privát és védett műveletekre. 
e A műveleteket határozzuk meg pontosan az adott osztályokra. 


Észrevehetjük, hogy ezek is egy ismétlődő folyamat lépései. Általában többször kell rajtuk 
végigmenni, hogy kényelmesen használható tervet kapjunk, melyet felhasználhatunk egy 
első vagy egy újabb megvalósításnál. Ha az itt leírtak szerinti elemezzük a tennivalókat és 
készítjük el az elvont adatábrázolást, az azzal az előnnyel jár, hogy viszonylag könnyű lesz 
az osztálykapcsolatok átrendezése a kód megírása után is. (Bár ez sohasem túl egyszerű.) 


Ha végeztünk, elkészítjük az osztályokat és visszatérünk felülvizsgálni a tervet annak alap- 
ján, amit a megvalósítás során megtudtunk. A következőkben ezeket a lépéseket egyenként 
vesszük sorra. 


23.4.3.1. Első lépés: keressünk osztályokat 


Keressük meg a fogalmakatjosztályokat és legalapvetőbb kapcsolataikat. A jó tervezés kul- 
csa a ,valóság" valamely részének közvetlen modellezése — vagyis a program fogalmainak 
osztályokra való leképezése, az osztályok közti kapcsolatok ábrázolása meghatározott mó- 
don (például öröklésseD, és mindezek ismételt végrehajtása különböző elvonatkoztatási 
szinteken. De hogyan fogjunk hozzá a fogalmak megkereséséhez? Milyen megközelítést 
célszerű követni, hogy eldönthessük, mely osztályokra van szükség? 


A legjobb, ha először magában a programban nézünk szét, ahelyett, hogy a számítógéptu- 
dós , fogalomzsákjában" keresgélnénk. Hallgassunk valakire, aki a rendszer elkészülte után 
annak szakértő felhasználója lesz, és valakire, aki a kiváltandó rendszer kissé elégedetlen 
felhasználója. Figyeljük meg, milyen szavakat használnak. 


Gyakran mondják, hogy a főnevek fognak megfelelni a programhoz szükséges osztályok- 
nak és objektumoknak; és ez többnyire így is van. Ezzel azonban semmiképpen sincs vége 
a történetnek. Az igék jelenthetik az objektumokon végzett műveleteket, a hagyományos 
(globális) függvényeket, melyek paramétereik értékei vagy osztályok alapján új értékeket 
állítanak elő. Az utóbbira példák a függvényobjektumok (function object, §18.4) és a mó- 
dosítók (manipulator, §21.4.69. Az olyan igék, mint a , bejár" vagy a ,véglegesít" ábrázolha- 
tók egy bejáró Citerátor) objektummal, illetve egy adatbázis commit műveletét végrehajtó 
objektummal. Még a melléknevek is gyakran használható módon ábrázolhatók osztályok- 
kal. Vegyük a , tárolható", ,párhuzamosan futó", , bejegyzett" és , lekötött" mellékneveket. 
Ezek is lehetnek osztályok, melyek lehetővé teszik a tervezőnek vagy a programozónak, 
hogy virtuális bázisosztályok meghatározása által kiválassza a később megtervezendő osz- 
tályok kívánt jellemzőit (§15.2.4). 
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Nem minden osztály felel meg programszintű fogalmaknak. Vannak például rendszer-erő- 
forrásokat vagy a megvalósítás fogalmait ábrázoló osztályok (424.3.1) is. Az is fontos, hogy 
elkerüljük a régi rendszer túl közeli modellezését. Például biztosan nem akarunk olyan 
rendszert készíteni, mely egy adatbázis köré épülve egy ,kézi rendszer" lehetőségeit utá- 
nozza és az egyénnek csak papírok fizikai tologatásának irányítását engedi meg. 


Az öröklés (inheritance) fogalmak közös tulajdonságainak ábrázolására szolgál. Legfonto- 
sabb felhasználása a hierarchikus felépítés ábrázolása az egyes fogalmakat képviselő osztá- 
lyok viselkedése alapján (§1.7, §12.2.6, §24.3.2). Erre néha úgy hivatkoznak, mint osztályo- 
zás (classification), sőt rendszertan (taxonomy). A közös tulajdonságokat aktívan keresni 
kell. Az általánosítás és az osztályozás magas szintű tevékenységek, melyek éleslátást igé- 
nyelnek, hogy hasznos és tartós eredményt adjanak. Egy közös alapnak egy általánosabb 
fogalmat kell ábrázolnia, nem pedig egy hasonló, az ábrázoláshoz esetleg kevesebb adatot 
igénylőt. 


Vegyük észre, hogy az osztályozást a rendszerben modellezett fogalmak alapján kell végez- 
ni, nem más területeken érvényes szemszögből. A matematikában például a kör az ellipszis 
egy fajtája, de a legtöbb programban a kört nem az ellipszisből és az ellipszist sem a körből 
származtatják. Azok a gyakran hallható érvek, hogy , azért, mert a matematikában ez a mód- 
ja" és ,azért, mert a kör az ellipszis részhalmaza", nem meggyőzőek és általában rosszak. 
Ennek az az oka, hogy a legtöbb programban a kör fő tulajdonsága az, hogy középpontja 
van és távolsága a kerületéig rögzített. A kör minden viselkedése (minden művelete) meg 
kell, hogy tartsa ezt a tulajdonságot (invariáns; §24.3.7.19. Másrészt az ellipszist két fókusz- 
pont jellemzi, melyeket sok programban egymástól függetlenül lehet módosítani. Ha ezek 
a fókuszpontok egybeesnek, az ellipszis olyan lesz, mint egy kör, de nem kör, mivel a mű- 
veletei nem tartják körnek. A legtöbb rendszerben ez a különbség úgy tükröződik, hogy 
van egy kör és egy ellipszis, amelyeknek vannak művelethalmazaik, de azok nem egymás 
részhalmazai. 


Nem az történik, hogy kiagyalunk egy osztályhalmazt az osztályok közötti kapcsolatokkal 
és felhasználjuk azokat a végső rendszerben. Inkább osztályok és kapcsolatok kezdeti hal- 
mazát alkotjuk meg, majd ezeket ismételten finomítjuk (423.4.3.59, hogy eljussunk egy 
olyan osztálykapcsolat-halmazig, mely eléggé általános, rugalmas és stabil ahhoz, hogy va- 


lódi segítséget nyújtson a rendszer későbbi megalkotásához. 


A kezdeti fő fogalmak/osztályok felvázolására a legjobb eszköz egy tábla, finomításukra pe- 
dig az alkalmazási terület szakértőivel és néhány barátunkkal folytatott vita, melynek során 
kialakíthatunk egy használható kezdeti szótárat és fogalmi vázlatot. Kevés ember tudja ezt 
egyedül elvégezni. A kiinduló osztályhalmazból valóban használható osztályhalmaz kiala- 
kításának egyik módja a rendszer utánzása, ahol a tervezők veszik át az osztályok szerepét. 
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A nyilvános vita feltárja a kezdeti ötletek hibáit, más megoldások keresésére ösztönöz és 
elősegíti a kialakuló terv közös megértését. A tevékenység lapokra írott feljegyzésekkel 
támogatható, amelyek később visszakereshetők. Az ilyen kártyákat rendszerint CRC kár- 
tyáknak nevezik ( Class, Responsibility, Collaborators", vagyis , Osztályok, Felelősség, 


Együttműködők", [Wirfs-Brock, 1990) a rájuk feljegyzett információk miatt. 


A használati eset (use case) a rendszer egy konkrét felhasználásának leírása. Íme a haszná- 
lati eset egyszerű példája egy telefonrendszerre: felvesszük a kagylót, tárcsázunk egy 
számot, a telefon a másik oldalon csenget, a másik oldalon felveszik a kagylót. Ilyen hasz- 
nálati esetek halmazának meghatározása hatalmas értékű lehet a fejlesztés minden szaka- 
szában, a tervezés elején pedig a használati esetek megkeresése segít, hogy megértsük, mit 
is próbálunk építeni. A tervezés alatt nyomon követhetjük velük a rendszer működési útját 
(például CRC kártyák használatával), hogy ellenőrizzük, van-e értelme a felhasználó szem- 
pontjából a rendszer osztályokkal és objektumokkal való viszonylag statikus leírásának; 
a programozás és tesztelés alatt pedig lehetséges helyzeteket modellezhetünk velük. Ily 
módon a használati eseteket a rendszer valószerűségének ellenőrzésére használhatjuk. 


A használati esetek a rendszert (dinamikusan) működő egységként tekintik. Ezért a terve- 
zőt abba a csapdába ejthetik, hogy a rendszer rendeltetését tartsa szem előtt, ami elvonja 
a figyelmét az osztályokkal ábrázolható, használható fogalmak keresésének elengedhetet- 
len feladatától. Különösen azok, akiknek a rendszerezett elemzés erősségük, de az objek- 
tumorientált programozásban és tervezésben kevés tapasztalattal rendelkeznek, a haszná- 
lati esetek hangsúlyozásával hajlamosak az eszközöket a célnak alárendelni. A használati 
esetek halmaza még nem tekinthető tervnek. Nem elég a rendszer használatát szem előtt 
tartani, gondolni kell annak felépítésére is. 


A tervezők csapata eredendően hiábavaló - és költséges — kísérlet csapdájába eshet, ha az 
összes használati esetet meg akarja keresni és le akarja írni. Amikor a rendszerhez osztályo- 
kat keresünk, ugyanígy eljön az idő, amikor ki kell mondani: , Ami sok, az sok. Itt az idő, 
hogy kipróbáljuk, amink van és lássuk, mi történik." A további fejlesztés során csak egy el- 
fogadható osztályhalmaz és egy elfogadható használatieset-halmaz használatával kaphatjuk 
meg a jó rendszer eléréséhez elengedhetetlen visszajelzést. Persze nehéz felismerni, mikor 
álljunk meg egy hasznos tevékenységben, különösen akkor, ha tudjuk, hogy később vissza 
kell térnünk a feladatot befejezni. 


Mennyi eset elegendő? Erre a kérdésre általában nem lehet választ adni. Az adott munka so- 
rán azonban eljön az idő, amikor a rendszer fő szolgáltatásainak legtöbbje működik és 
a szokatlanabb problémák, illetve a hibakezelési kérdések jó részét is érintettük. Ekkor ide- 
je elvégezni a tervezés és programozás következő lépését. 
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Amikor a program felhasználási területeit használati esetek segítségével próbáljuk felbe- 
csülni, hasznos lehet azokat elsődleges és másodlagos használati esetekre szétválasztani. 
Az elsődlegesek a rendszer legáltalánosabb, , normális" tevékenységeit, a másodlagosak 
a szokatlanabb, illetve a hibakezeléssel kapcsolatos tevékenységeket írják le. A másodlagos 
használati esetre példa a , telefonhívás" egy változata, ahol a hívott állomás kagylóját fel- 
emelték, mert éppen a hívó számát tárcsázzák. Gyakran mondják, hogy ha az elsődleges 
használati esetek 8090-át és néhány másodlagosat már kipróbáltunk, ideje továbbmenni, de 
mivel előre nem tudhatjuk, mi alkotja az ,összes esetet", ez csupán irányelv. Itt a tapaszta- 
lat és a jó érzék számít. 


A fogalmak, műveletek és kapcsolatok a programok alkalmazási területeiből természetsze- 
rűen adódnak vagy az osztályszerkezeten végzett további munkából születnek. Ezek jelzik, 
hogy alapvetően értjük a program működését és képesek vagyunk az alapfogalmak osztá- 
lyozására. Például a tűzoltókocsi egy tűzoltó gép, ami egy teherautó, ami egy jármű. 
A §23.4.3.2 és §23.4.5 pontok bemutatnak néhány módszert, amelyekkel az osztályokra és 
osztályhierarchiákra a továbbfejlesztés szándékával nézhetünk. 


Óvakodjunk a rajzos tervezéstől! Természetesen a fejlesztés bizonyos szakaszában megkér- 
nek majd, hogy mutassuk be a tervet valakinek, és akkor bemutatunk egy sereg diagramot, 
melyek az épülő rendszer felépítését magyarázzák. Ez nagyon hasznos lehet, mert segít, 
hogy figyelmünket arra összpontosítsuk, ami a rendszerben fontos, és kénytelenek vagyunk 
ötleteinket mások által is érthető szavakkal kifejezni. A bemutató értékes tervezési eszköz. 
Elkészítése azzal a céllal, hogy valóban megértsék azok, akiket érdekel és akik képesek épí- 
tő bírálatot alkotni, jó gyakorlat a gondolatok megfogalmazására és tiszta kifejezésére. 


A terv hivatalos bemutatása azonban veszélyes is lehet, mivel erős a kísértés, hogy az ideá- 
lis rendszert mutassuk be - olyat, amit bárcsak meg tudnánk építeni, egy rendszert, melyre 
a vezetőség vágyik — ahelyett, amivel rendelkezünk, és amit elfogadható idő alatt meg tu- 
dunk csinálni. Amikor különböző megközelítések vetélkednek és a döntéshozók nem iga- 
zán értik a részleteket (vagy nem is törődnek azokkal], a bemutatók hazugságversennyé 
válnak, amelyben a leggrandiózusabb rendszert bemutató csapat nyeri el a munkát. Ilyen 
esetekben a gondolatok világos kifejezését gyakran szakzsargon és rövidítések helyettesí- 
tik. Ha ilyen bemutatót hallgatunk — és különösen, ha döntéshozók vagyunk és fejlesztési 
erőforrásokról rendelkezünk — létfontosságú, hogy képesek legyünk különbséget tenni 
vágyálom és reális terv között. A jó bemutatóanyag nem garantálja a leírt rendszer minősé- 
gét. Tapasztalatom szerint a valós problémákra összpontosító cégek, amikor eredményeik 
bemutatására kerül sor, rövidre fogják a szót azokhoz képest, akik kevésbé érdekeltek va- 
lós rendszerek elkészítésében. 
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Amikor osztályokkal ábrázolandó fogalmakat keresünk, vegyük észre, hogy a rendszernek 
vannak olyan fontos tulajdonságai is, melyeket nem ábrázolhatunk osztályokkal. A megbíz- 
hatóság, a teljesítmény, a tesztelhetőség fontos mérhető rendszertulajdonságok. Mégsem le- 
het még a legtisztábban objektumokra alapozott rendszer megbízhatóságát sem egy , meg- 
bízhatósági objektummal" ábrázolni. A rendszerben mindenütt jelenlevő tulajdonságok 
meghatározhatók, megtervezhetők és méréssel igazolhatók; gondot kell fordítani rájuk 
minden osztálynál, és tükröződniük kell az egyes osztályok és összetevők tervezési és meg- 
valósítási szabályaiban (423.4.39. 


23.4.3.2. Második lépés: határozzuk meg a műveleteket 


Finomítsuk az osztályokat a rajtuk végezhető műveletek meghatározásával. Természetes, 
hogy nem lehet az osztályok keresését elválasztani attól, hogy kigondoljuk, milyen műve- 
leteket kell rajtuk végezni. Gyakorlati különbség van azonban abban, hogy az osztályok ke- 
resésekor a fő fogalmakra összpontosítunk és tudatosan háttérbe szorítjuk a számítástech- 
nikai szempontokat, míg a műveletek meghatározásakor azt tartjuk szem előtt, hogy teljes 
és használható művelethalmazt találjunk. Általában túl nehéz egyszerre mindkettőre gon- 


dolni, különösen azért, mert az egymással kapcsolatban lévő osztályokat együtt kell meg- 
tervezni, de ebben is segíthetnek a CRC kártyák (423.4.3.19. 


Amikor az a kérdés, milyen szolgáltatásokról gondoskodjunk, többféle megközelítés lehet- 
séges. Én a következő stratégiát javaslom: 


1. Gondoljuk végig, hogyan jön létre, hogyan másolódik (ha egyáltalán másoló- 
dik) és hogyan semmisül meg az osztály egy objektuma. 

2. Határozzuk meg az osztály által igényelt műveletek minimális halmazát. Általá- 
ban ezek lesznek a tagfüggvények. 

3. Gondoljuk végig, milyen műveleteket lehetne még megadni a kényelmesebb je- 
lölés érdekében. Csak néhány valóban fontos műveletet adjunk meg. Ezekből 
lesznek a nem tag segédfüggvények (410.3.29. 

4. Gondoljuk végig, mely műveleteknek kell virtuálisaknak lenniük, vagyis olyan 
műveleteknek, melyekkel az osztály felületként szolgálhat egy származtatott 
osztály által adott megvalósítás számára. 

5. Gondoljuk végig, milyen közös elnevezési módszert és szolgáltatásokat biztosít- 
hatunk egy összetevő minden osztályára vonatkozóan. 


Világos, hogy ezek a minimalizmus elvei. Sokkal könnyebb minden hasznosnak gondolt 
függvényt megadni és minden műveletet virtuálissá tenni. Minél több függvényünk van 
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nyek korlátozni fogják a rendszer megvalósítását, további fejlődését. Nevezetesen azok 
a függvények, melyek egy osztály egy objektuma állapotának valamely részét közvetlenül 
olvassák vagy írják, gyakran egyedi megvalósítást követelnek az osztálytól és komoly mér- 
tékben korlátozzák az újratervezés lehetőségét. Az ilyen függvények az elvont ábrázolást 
a fogalom szintjéről a megvalósítás szintjére szállítják le. A függvények hozzáadása a prog- 
ramozónak is több munkát jelent — és a tervezőnek is, a következő újratervezéskor. Sokkal 
könnyebb egy függvényt megadni, amikor világossá vált, hogy szükség van rá, mint eltávo- 
lítani azt, ha kolonccá válik. 


Annak oka, hogy egy függvényről világosan el kell dönteni, hogy virtuális legyen vagy sem, 
és ez nem alapértelmezett viselkedés vagy megvalósítási részlet, az, hogy egy függvény vir- 
tuálissá tétele alapjaiban befolyásolja osztályának használatát és az osztály kapcsolatait más 
osztályokkal. Egy olyan osztály objektumainak elrendezése, melyben akár csak egyetlen 
virtuális függvény is van, jelentős mértékben különbözik a C vagy Fortran nyelvek objektu- 
maitól. A virtuális függvényt is tartalmazó osztályok felületet nyújthatnak a később 
definiálandó osztályok számára, de egy virtuális függvény egyben függést is jelent azoktól 


(424.3.2.1. 
Vegyük észre, hogy a minimalizmus inkább több, mint kevesebb munkát követel a tervezőtől. 


Amikor kiválasztjuk a műveleteket, fontos, hogy inkább arra összpontosítsunk, mit kell ten- 
ni, nem pedig arra, hogyan tegyük. Vagyis inkább a kívánt viselkedésre, mint a megvalósí- 
tás kérdéseire figyeljünk. 


Néha hasznos az osztályok műveleteit aszerint osztályozni, hogyan használják az objektu- 
mok belső állapotát: 


Alapvető műveletek: konstruktorok, destruktorok és másoló operátorok. 
Lekérdezések: műveletek, melyek nem módosítják egy objektum állapotát. 
Módosítók: műveletek, melyek módosítják egy objektum állapotát. 


..... 


Konverziók: műveletek, melyek más típusú objektumot hoznak létre annak az 
objektumnak az értéke (állapota) alapján, amelyre alkalmazzuk őket. 

4 Bejárók: operátorok, melyek a tartalmazott objektumsorozatokhoz való hozzáfé- 
rést, illetve azok használatát teszik lehetővé. 


A fentiek nem egymást kizáró kategóriák. Egy bejáró például lehet egyben lekérdező vagy 
módosító is. Ezek a kategóriák egyszerűen egy osztályozást jelentenek, mely segíthet az 
osztályfelületek megtervezésében. Természetesen lehetségesek más osztályozás is. Az ilyen 
osztályozások különösen hasznosak az összetevőkön belüli osztályok egységességének 
fenntartásában. 
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A C44 a lekérdezők és módosítók megkülönböztetését a konstans és nem konstans tag- 
függvényekkel segíti. Ugyanígy a konstruktorok, destruktorok, másoló operátorok és kon- 
verziós függvények is közvetlenül támogatottak. 


23.4.3.3. Harmadik lépés: határozzuk meg az összefüggéseket 


Finomítsuk az osztályokat az összefüggések meghatározásával. A különféle összefüggése- 
ket a 424.3 tárgyalja. A tervezéssel kapcsolatosan vizsgálandó fő összefüggések a paramé- 
terezési, öröklési (inheritance) és használati (use) kapcsolatok. Mindegyiknél meg kell vizs- 
gálni, mit jelent, hogy az osztály a rendszer egyetlen tulajdonságáért felelős. Felelősnek len- 
ni biztos, hogy nem azt jelenti, hogy az osztály az összes adatot maga kell, hogy tartalmaz- 
za, vagy hogy az összes szükséges műveletet közvetlenül tagfüggvényei kell, hogy végre- 
hajtsák. Ellenkezőleg: az, hogy minden osztálynak egyetlen felelősségi területe van, azt biz- 
tosítja, hogy egy osztály munkája jobbára abból áll, hogy a kéréseket egy másik osztályhoz 
irányítja, mely az adott részfeladatért felelős. Legyünk azonban óvatosak, mert e módszer 
túlzott mértékű használata kis hatékonyságú és áttekinthetetlen tervekhez vezet, azáltal, 
hogy olyan mértékben elburjánzanak az osztályok és objektumok, hogy más munka nem 
történik, mint a kérések továbbítása. Amit az adott helyen és időben meg lehet tenni, azt 
meg kell tenni. 


Annak szükségessége, hogy az öröklési és használati kapcsolatokat a tervezési szakaszban 
vizsgáljuk (és nem csak a megvalósítás során), közvetlenül következik abból, hogy az osz- 
tályokat fogalmak ábrázolására használjuk. Ez pedig azt is magában foglalja, hogy nem az 
egyedi osztály, hanem a komponens (423.4.3, §24.4) a tervezés valódi egysége. 


A paraméterezés — mely gyakran sablonok (template) használatához vezet — egy mód arra, 
hogy a mögöttes függéseket nyilvánvalóvá tegyük, úgy, hogy új fogalmak hozzáadása nél- 
kül több lehetséges megoldás legyen. Gyakran választhatunk, meghagyunk-e valamit kör- 
nyezettől függő — egy öröklési fa ágaként ábrázolt — elemként, vagy inkább paramétert 
használunk (§24.4.1). 


23.4.3.4. Negyedik lépés: határozzuk meg a felületeket 


Határozzuk meg a felületeket. A privát függvényekkel a tervezési szakaszban nem kell fog- 
lalkozni. Azt, hogy ekkor a megvalósítás mely kérdéseit vesszük figyelembe, legjobb a har- 
madik lépésben, a függési viszonyok meghatározásakor eldönteni. Világosabban kifejezve: 
vegyük alapszabálynak, hogy ha egy osztálynak nem lehetséges legalább két jelentősen el- 


térő megvalósítása, akkor valószínű, hogy ezzel az osztállyal valami nincs rendben, és va- 
lójában álcázott megvalósítással (implementation), nem pedig igazi fogalommal állunk 
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szemben. Sok esetben az , Eléggé független ennek az osztálynak a felülete a megvalósítás 
módjától?" kérdés jó megközelítése, ha megvizsgáljuk, alkalmazható-e az osztályra valami- 
lyen takarékos kiértékelési módszer ( lusta kiértékelés", lazy evaluation). 


Vegyük észre, hogy a nyilvános (public) alaposztályok és barát függvények (friend) az osz- 
tály nyilvános felületének részei (lásd még §11.5 és §24.4.2). Kifizetődő lehet, ha külön fe- 
lületekről gondoskodunk az öröklés, illetve az általános felhasználók számára, azáltal, hogy 
külön protected és public felületeket adunk meg. 


Ez az a lépés, amelyben a paraméterek pontos típusát meghatározzuk. Az az ideális, ha 
annyi statikus, programszintű típusokat tartalmazó felületünk van, amennyi csak lehetséges 
(424.2.3 és §24.4.29. 


Amikor a felületeket (interface) meghatározzuk, vigyázni kell azoknál az osztályoknál, ahol 
a műveletek látszólag több fogalmi szintet támogatnak. A File osztály egyes tagfüggvényei 
például File descriptor (fájlleíró) típusú paramétereket kaphatnak, mások pedig karakter- 
lánc paramétereket, melyek fájlneveket jelölnek. A File descriptor műveletek más fogalmi 
szinten dolgoznak, mint a fájlnév-műveletek, így elgondolkozhatunk azon, vajon ugyanab- 
ba az osztályba tartoznak-e. Lehet, hogy jobb lenne, ha két fájlosztályunk lenne, az egyik 
a fájlleíró fogalmának támogatására, a másik a fájlnév fogalomhoz. Általában egy osztály 
minden művelete ugyanazt a fogalmi szintet kell, hogy támogassa. Ha nem így van, át kell 
szervezni az osztályt és a vele kapcsolatban lévő osztályokat. 


23.4.3.5. Osztályhierarchiák újraszervezése 

Az első és a harmadik lépésben megvizsgáltuk az osztályokat és osztályhierarchiákat, hogy 
lássuk, megfelelően kiszolgálják-e igényeinket. A válasz általában nem és ilyenkor át kell 
szerveznünk, osztályainkat, hogy tökéletesítsük a szerkezetet, a tervet vagy éppen a meg- 
valósítás módját. Az osztályhierarchia legközönségesebb átszervezési módszere két osztály 
közös részének kiemelése egy új osztályba, illetve az osztály két új osztályra bontása. Mind- 
két esetben három osztály lesz az eredmény: egy bázisosztály (base class) és két származ- 
tatott osztály (derived class). Mikor kell így újraszervezni? Mi jelzi azt, hogy egy ilyen újra- 
szervezés hasznos lehet? 

Sajnos ezekre a kérdésekre nincsenek egyszerű, általános válaszok. Ez nem igazán megle- 
pő, mert amiről beszélünk, nem apró részletek, hanem egy rendszer alapfogalmainak mó- 
dosítása. Az alapvető — bár nem egyszerű — feladat az osztályok közös tulajdonságainak 
megkeresése és a közös rész kiemelése. Azt, hogy mi számít közösnek, nem lehet ponto- 
san meghatározni, de a közös résznek a fogalmak közti, és nem csak a megvalósítás kényel- 
mét szolgáló közösséget kell tükröznie. Arról, hogy két vagy több osztály olyan közös tu- 
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lajdonságokkal rendelkezik, melyeket egy bázisosztályban foglalhatunk össze, a közös 
használati minta, a művelethalmazok hasonlósága, illetve a hasonló megvalósítás árulko- 
dik, valamint az, hogy ezek az osztályok gyakran együtt merülnek fel a tervezési viták so- 
rán. Ezzel szemben egy osztály valószínűleg két másikra bontható, ha műveleteinek rész- 
halmazai eltérő használati mintájúak, ha ezen részhalmazok az ábrázolás külön részhalma- 
zaihoz férnek hozzá, vagy ha az osztály egymással nyilvánvalóan nem kapcsolatos tervezé- 
si viták során merül fel. A rokon osztályok halmazának sablonba (template) foglalása rend- 


szerezett módot ad a szükséges alternetívák biztosítására (424.4.1). 


Az osztályok és fogalmak közti szoros kapcsolatok miatt az osztályhierarchiák szervezési 
problémái gyakran mint az osztályok elnevezési problémái merülnek fel. Ha az osztályne- 
vek nehézkesen hangzanak vagy az osztályhierarchiákból következő osztályozások túlsá- 
gosan bonyolultak, valószínűleg itt az alkalom, hogy tökéletesítsük a hierarchiákat. Véle- 
ményem szerint két ember sokkal jobban tud egy osztályhierarchiát elemezni, mint egy. Ha 
történetesen nincs valaki, akivel egy tervet meg tudnánk vitatni, hasznos lehet, ha írunk egy 
bevezető tervismertetőt, amelyben az osztályok neveit használjuk. 


A terv egyik legfontosabb célkitűzése olyan felületek (interface) biztosítása, melyek a vál- 
tozások során állandóak maradnak (423.4.2). Ezt gyakran úgy érhetjük el legjobban, ha egy 
osztályt, amelytől számos osztály és függvény függ, olyan absztrakt osztállyá teszünk, mely 
csak nagyon általános műveleteket biztosít. A részletesebb műveletek jobb, ha egyedi célú 
származtatott osztályokhoz kapcsolódnak, melyektől kevesebb osztály és függvény függ 
közvetlenül. Világosabban: minél több osztály függ egy osztálytól, annál általánosabbnak 
kell lennie. 


Erős a kísértés, hogy egy sokak által használt osztályhoz műveleteket (és adatokaD) tegyünk 
hozzá. Ezt gyakran úgy tekintik, mint ami egy osztályt használhatóbbá és (további) változ- 
tatást kevésbé igénylővé tesz. Pedig az eredmény csak annyi, hogy a felület meghízik ( kö- 
vér felület", §24.4.3) és olyan adattagjai lesznek, melyek számos gyengén kapcsolódó szol- 
gáltatást támogatnak. Ez ismét azzal jár, hogy az osztályt módosítani kell, amikor az általa 
támogatott osztályok közül akár csak egy is jelentősen megváltozik. Ez viszont magával 
vonja olyan felhasználói osztályok és származtatott osztályok módosítását is, melyek nyil- 
vánvalóan nincsenek vele kapcsolatban. Ahelyett, hogy bonyolítanánk egy, a tervben köz- 
ponti szerepet játszó osztályt, rendszerint általánosnak és elvontnak kellene hagynunk. Ha 
szükséges, az egyedi szolgáltatásokat származtatott osztályokként kell biztosítani. (Példákat 
lásd [Martin 1995D. 


Ez a gondolatfüzér absztrakt (abstrac0) osztályok hierarchiájához vezet, ahol a gyökérhez 
közeli osztályok a legáltalánosabbak, és ezektől függ a legtöbb más osztály és függvény. 
A levél osztályok a legegyedibbek és csak nagyon kevés kódrész függ közvetlenül tőlük. 
Példaként említhetnénk az /val box hierarchia végső változatát (§12.4.3, §12.4.4. 
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23.4.3.6. Modellek használata 


Amikor cikket írok, egy megfelelő modellt próbálok követni. Vagyis ahelyett, hogy azonnal 
elkezdem a gépelést, hasonló témájú cikkeket keresek, hogy lássam, találok-e olyat, amely 
a cikkem kezdeti mintájaként szolgálhat. Ha az általam választott modell egy saját, rokon 
témáról szóló cikk, még arra is képes vagyok, hogy helyükön hagyok szövegrészeket, má- 
sokat szükség szerint módosítok és új információt csak ott teszek hozzá, ahol mondandóm 
logikája megkívánja. Ez a könyv például ilyen módon íródott, az első és második kiadás 
alapján. Ennek a módszernek szélsőséges esete egy levélsablon használata. Ekkor egysze- 
rűen egy nevet írok be és esetleg hozzáírok még néhány sort, hogy a levél , személyre szó- 
ló" legyen. Az ilyen leveleket lényegében úgy írom meg, hogy a sablont csak az alapmo- 


delltől eltérő részekkel egészítem ki. 


A létező rendszerek ilyen, új rendszerek modelljeiként való felhasználása általános eljárás 
az alkotó törekvések minden formájánál. Amikor csak lehetséges, a tervezés és programo- 
zás előző munkára kell, hogy alapozódjon. Ez korlátozza a tervező szabadságát, de lehető- 
vé teszi, hogy figyelmét egyszerre csak néhány kérdésre összpontosítsa. Egy nagy projekt 
tiszta lappal indítása frissítő hatással lehet, de könnyen , mérgezővé" is válhat, mert a terve- 
zési módszerek közötti kóválygást eredményezheti. Ennek ellenére, ha van modellünk, az 
nem jelent korlátozást és nem követeli meg, hogy szolgai módon kövessük; egyszerűen 
megszabadítja a tervezőt attól, hogy egy tervet egyszerre csak egy szempontból közelíthes- 


sen meg. 


Vegyük észre, hogy a modellek használata elkerülhetetlen, mivel minden terv tervezőinek 
tapasztalataiból tevődik össze. Egy adott modell birtokában a modellválasztás tudatos elha- 
tározássá válik, feltételezéseink megalapozottak, a használt kifejezések köre pedig megha- 
tározott lesz, a tervnek lesz egy kezdeti váza és nő a valószínűsége, hogy a tervezők meg 
tudnak egyezni egy közös megközelítésben. 


Természetesen a kiinduló modell kiválasztása önmagában is fontos tervezési döntés, amely 
gyakran csak a lehetséges modellek keresése és az alternatívák gondos kiértékelése után 
hozható meg. Továbbá sok esetben egy modell csak akkor felel meg, ha megértjük, hogy 
az elképzeléseknek egy új konkrét alkalmazáshoz való igazítása számos módosítást igé- 
nyel. A programtervezés nem könnyű, így minden megszerezhető segítségre szükségünk 
van. Nem szabad visszautasítanunk a modellek használatát, csak a , rossz utánzás" erőlteté- 
sét. Az utánzás a hízelgés legőszintébb módja, és a modellek és előző munkák ösztönzés- 
ként való felhasználása — a tulajdon és a másolás jogának törvényes határain belül — az in- 
novatív munka minden területen elfogadható módszer: ami jó volt Shakespeare-nek, az jó 
nekünk is. Vannak, akik a modellek ilyen használatát a tervezésben , terv-újrahasznosítás- 


nak" nevezik. 
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Az általánosan használt, több programban előforduló elemek feljegyzése — az általuk meg- 
oldott probléma és használatuk feltételeinek leírásával együtt — kézenfekvő ötlet; feltéve, 
hogy eszünkbe jut. Az ilyen általános és hasznos tervezési elemek leírására általában 
a minta (pattern) szót használjuk, a minták dokumentálásának és használatának pedig ko- 
moly irodalma van (pl. Gamma, 1994] és (Coplien, 1995). 


Célszerű, hogy a tervező ismerje az adott alkalmazási terület népszerű mintáit. Mint progra- 
mozó, olyan mintákat részesítek előnyben, melyekhez valamilyen kód is tartozik, ami pél- 
daként tekinthető. Mint a legtöbb ember, egy általános ötletet (ebben az esetben mintát) ak- 
kor tartok a legjobbnak, ha segítségemre van egy konkrét példa is (ebben az esetben egy, 
a minta használatát illusztráló kódrészlet). Akik gyakran használnak mintákat, szakzsargont 
használnak egymás között, ami sajnos privát nyelvvé válhat, ami kívülállók számára lehe- 
tetlenné teszi a megértést. Mint mindig, elengedhetetlen a megfelelő kommunikáció bizto- 
sítása a projekt különböző részeiben résztvevők (423.3) és általában a tervező és programo- 
zó közösségek között. 


Minden sikeres nagy rendszer egy valamivel kisebb működő rendszer áttervezése. Nem is- 
merek kivételt e szabály alól. Még leginkább olyan tervek jutnak eszembe, melyek évekig 
szenvedtek zűrzavaros állapotban és nagy költséggel, évekkel a tervezett befejezési dátum 
után esetleg sikeresek lettek. Az ilyen projektek eredménye - szándékolatlanul és persze el- 
ismerés nélkül — először működésképtelen rendszer lett, amit később működőképessé tet- 
tek, végül újraterveztek olyan rendszerré, mely megközelíti az eredeti célkitűzéseket. Ebből 
következik, hogy ostobaság egy nagy rendszert újonnan megtervezni és megépíteni, pon- 
tosan követve a legfrissebb elveket. Minél nagyobb és nagyratörőbb a rendszer, melyet 
megcéloztunk, annál fontosabb, hogy legyen egy modellünk, melyből dolgozunk. Egy 
nagy rendszerhez az egyetlen valóban elfogadható modell egy valamivel kisebb, működő 
rokon rendszer. 


23.4.4. Kísérletezés és elemzés 


Egy igényes fejlesztés kezdetén nem tudjuk a módját, hogyan alkossuk meg legjobban 
a rendszert. Gyakran még azt sem tudjuk pontosan, mit kellene a rendszernek tennie, mi- 
vel a konkrétumok csak akkor tisztulnak ki, amikor a rendszert építjük, teszteljük és hasz- 
náljuk. Hogyan kapjuk meg a teljes rendszer felépítése előtt a szükséges információkat ah- 
hoz, hogy megértsük, melyek a jelentős tervezési döntések és felbecsüljük azok buktatóit? 
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Kísérleteket folytatunk. Mihelyt van mit, elemezzük a terveket és azok megvalósítását is. 
A leggyakoribb és legfontosabb a lehetőségek megvitatása. A tervezés általában közösségi 
tevékenység, melyben a tervek bemutatók és viták által fejlődnek. A legfontosabb tervező- 
eszköz a tábla; enélkül az embrionális állapotú tervezési fogalmak nem tudnak kifejlődni és 
elterjedni a tervezők és programozók között. 


A kísérlet legnépszerűbb formája egy prototípus építése, vagyis a rendszer vagy egy részé- 
nek lekicsinyített változatban való létrehozása. A prototípus teljesítményére nézve nincsenek 
szigorú előírások, általában elegendő a gépi és programozási környezetbeli erőforrás, a ter- 
vezők és programozók pedig igyekeznek különösen képzettnek, tapasztaltnak és motivált- 
nak látszani. Arról van szó, hogy egy változatot a lehető leggyorsabban futtatni lehessen, 


hogy lehetővé tegyük a tervezési és megvalósítási módszerek választékának felderítését. 


Ez a megközelítés nagyon sikeres lehet, ha jól csináljuk, de lehet ürügy a pongyolaságra is. 
Az a probléma, hogy a prototípus súlypontja a lehetőségek felderítésétől eltolódhat , a lehe- 
tő leghamarabb valamilyen működőképes rendszert kapni" felé. Ez könnyen a prototípus 
belső felépítése iránti érdektelenséghez ( végül is csak prototípusról van szó") és a tervezé- 
si erőfeszítések elhanyagolásához vezet, mert a prototípus gyors elkészítése ezekkel szem- 
ben előnyt élvez. Az a bökkenő, hogy az ily módon elkészített változatban sokszor nyoma 
sincs az erőforrások helyes felhasználásának vagy a módosíthatóság lehetőségének, miköz- 
ben egy , majdnem teljes" rendszer illúzióját adja. Szinte törvényszerű, hogy a prototípus 
nem rendelkezik azzal a belső felépítéssel, hatékonysággal és áttekinthetőséggel, mely 
megengedné, hogy rajta keresztül a valós használatot felmérhessük. Következésképpen 
egy , prototípus" , melyből , majdnem termék?" lesz, elszívja azt az időt és energiát, amit a va- 
lódi termékre lehetett volna fordítani. Mind a fejlesztők, mind a vezetők számára kísértést 
jelent, hogy a prototípusból terméket csináljanak és a , teljesítmény megtervezését" elha- 
lasszák a következő kiadásig. A prototípuskészítésnek ez a helytelen használata tagadása 
mindennek, amiért a tervezés létezik. 


Rokon probléma, hogy a prototípus fejlesztői beleszerethetnek az eszközeikbe. Elfelejthe- 
tik, hogy az általuk élvezett kényelem költségeit egy valódi rendszer nem mindig engedhe- 
ti meg magának, és az a korlátok nélküli szabadság, melyet kis kutatócsoportjuk nyújtott, 
nemigen tartható fenn egy nagyobb közösségben, mely szoros -— és egymástól függő — ha- 
táridők szerint dolgozik. 


Másrészről, a prototípusok felbecsülhetetlen értékűek. Vegyük például egy felhasználói fe- 
lület tervezését. Ebben az esetben a rendszer a felhasználóval közvetlen kölcsönhatásban 
nem levő részének belső felépítése tényleg lényegtelen, és a prototípus használatán kívül 
nincs más lehetséges mód, hogy tapasztalatokat szerezzünk arról, mi a véleménye a fel- 
használóknak a rendszer külsejével és használatával kapcsolatban. De példaként vehetjük 
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az ellenkezőjét is, egy olyan prototípust, melyet szigorúan egy program belső működésé- 
nek tanulmányozására terveztek. Itt a felhasználói felület lehet kezdetleges — lehetőség sze- 
rint a valódi felhasználók helyett szimuláltakkal. 


A prototípuskészítés a kísérletezés egy módja. Eredményei pedig azok a meglátások kelle- 
nek, hogy legyenek, melyeket nem maga a prototípus, hanem annak építése hoz magával. 
Tulajdonképpen a prototípus legfőbb ismérveként a tökéletlenséget kellene meghatározni, 
hogy világos legyen, ez csupán kísérleti eszköz és nem válhat termékké nagymértékű újra- 
tervezés nélkül. Ha , tökéletlen" prototípusunk van, az segít, hogy a kísérletre összpontosít- 
sunk és a lehető legkisebbre csökkenti annak veszélyét, hogy a prototípusból termék 
legyen, valamint megszünteti azt a kísértést is, hogy a termék tervezését túl szorosan a pro- 
totípusra alapozzuk, elfelejtve vagy elhanyagolva annak eredendő korlátait. A prototípus 
használat után eldobandó. 


Vannak olyan kísérleti módszerek is, melyeket a prototípuskészítés helyett alkalmazhatunk. 
Ahol ezek használhatók, gyakran előnyben is részesítjük őket, mert szigorúbbak és keve- 
sebb tervezői időt és rendszer-erőforrást igényelnek. Ilyenek például a matematikai model- 
lek és a különféle szimulátorok. Tulajdonképpen fel is vázolhatunk egy folyamatot, 
a matematikai modellektől az egyre részletesebb szimulációkon, a prototípusokon, és 
a részleges megvalósításon át a teljes rendszerig. 


Ez ahhoz az ötlethez vezet, hogy egy rendszert a kezdeti tervből és megvalósításból több- 
szöri újratervezéssel és újbóli elkészítéssel finomítsunk. Ez az ideális módszer, de nagyon 
nagy igényeket támaszthat a tervezői és fejlesztői eszközökkel szemben. A megközelítés 
azzal a kockázattal is jár, hogy túl sok kód készül a kezdeti döntések alapján, így egy jobb 
tervet nem lehet megvalósítani. Így ez a stratégia egyelőre csak kis és közepes méretű prog- 
ramok készítésénél működik jól, melyekben nem valószínű, hogy az átfogó tervek különö- 
sebben módosulnának, illetve a programok első kiadása utáni újratervezésekre és újbóli 
megvalósításokra, ahol elkerülhetetlen az ilyen megközelítés. 


A tervezési lehetőségek áttekintésére szolgáló kísérleteken kívül egy terv vagy megvalósí- 
tás elemzése önmagában is ötleteket adhat. A legnagyobb segítség például az osztályok 
közti különböző összefüggések (§424.3) tanulmányozása lehet, de nem elhanyagolhatók 
a hagyományos eszközök sem, mint a hívási fák (call graphs) megrajzolása, a teljesítmény- 
mérések stb. 


Ne feledjük, hogy a fogalmak meghatározása (az elemzési szakasz , kimenete") és a terve- 
zés során éppúgy elkövethetünk hibákat, mint a megvalósítás folyamán. Valójában még 
többet is, mivel ezen tevékenységek eredménye kevésbé konkrét, kevésbé pontosan meg- 
határozott, nem , végrehajtható" és általában nem támogatják olyan kifinomult eszközök, 
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mint amilyenek a megvalósítás elemzéséhez és ellenőrzéséhez használhatók. Ha a tervezés 
kifejezésére használt nyelvet vagy jelölésmódot formálisabbá tesszük, valamilyen mértékig 
ilyen eszközt adhatunk a tervező kezébe, ezt azonban nem tehetjük annak az árán, hogy 
szegényebbé tesszük a megvalósításra használt programozási nyelvet (424.3.19. Ugyanak- 
kor egy formális jelölésmód maga is problémák forrása lehet, például ha a használt jelölés- 
rendszer nem illik jól arra a gyakorlati problémára, melyre alkalmazzuk; amikor a formai 
követelmények szigora túllépi a résztvevő tervezők és programozók matematikai felké- 
szültségét és érettségét; vagy amikor a formális leírás elszakad a leírandó rendszertől. 


A tervezés eredendően ki van téve a hibáknak és nehéz támogatni hatékony eszközökkel. 
Ezért nélkülözhetetlen a tapasztalat és a visszajelzés. Következésképpen alapvetően hibás 
a programfejlesztést egyenes vonalú folyamatként tekinteni, mely az elemzéssel kezdődik és 
a teszteléssel végződik. Figyelmet kell fordítani az ismételt tervezésre és megvalósításra, 
hogy a fejlesztés különböző szakaszaiban elegendő visszajelzésünk legyen a tapasztaltakról. 


23.4.5. Tesztelés 


Az a program, melyet nem teszteltek, nem tekinthető működőnek. Az eszménykép, hogy 
egy programot úgy készítsünk el, hogy már az első alkalommal működjön, a legegyszerűbb 
programokat kivéve elérhetetlen. Törekednünk kell erre, de nem szabad ostobán azt hin- 
nünk, hogy tesztelni könnyű. 


A , Hogyan teszteljünk?" olyan kérdés, melyre nem lehet csak úgy általában válaszolni. 
A ,Mikor teszteljünk?" kérdésre azonban van általános válasz: olyan hamar és olyan gyak- 
ran, amennyire csak lehetséges. A tesztelési módszert célszerű már a tervezés és megvalósí- 
tás részeként, de legalább azokkal párhuzamosan kidolgozni. Mihelyt van egy futó 
rendszer, el kell kezdeni a tesztelést. A komoly tesztelés elhalasztása a , befejezés" utánig 
a határidők csúszását és /vagy hibás kiadást eredményezhet. 


Ha csak lehetséges, a rendszert úgy kell megtervezni, hogy viszonylag könnyen tesztelhe- 
tő legyen. Az ellenőrzést gyakran bele lehet tervezni a rendszerbe. Néha ezt nem tesszük, 
attól való félelmünkben, hogy a futási idejű tesztelés rontja a hatékonyságot, vagy hogy az 
ellenőrzéshez szükséges redundáns elemek túlságosan nagy adatszerkezeteket eredmé- 
nyeznek. Az ilyen félelem rendszerint alaptalan, mert a legtöbb tesztkód szükség esetén le- 
választható a tényleges kódról, mielőtt a rendszert átadjuk. Az assertion-ök (424.3.7.2) hasz- 
nálata néha hasznos lehet. 

Maguknál a teszteknél is fontosabb, hogy a rendszer olyan felépítésű legyen, ami elfogad- 
ható esélyt ad arra, hogy saját magunkat és felhasználóinkat/fogyasztóinkat meggyőzzük 
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arról, hogy a hibákat statikus ellenőrzés, statikus elemzés és tesztelés együttes használatá- 
val ki tudjuk küszöbölni. Ahol a hibatűrés biztosítására kidolgoztak valamilyen módszert 
(§14.9), ott általában a tesztelés is beépíthető a teljes tervbe. 


Ha a tervezési szakaszban a tesztelési kérdésekkel egyáltalán nem számoltunk, akkor az el- 
lenőrzéssel, a határidők betartásával és a program módosításával problémáink lesznek. 
Az osztályfelületek és az osztályfüggések rendszerint jó kiindulópontot jelentenek a teszte- 
lési módszer kidolgozásához(§24.3, §24.4.2). 


Rendszerint nehéz meghatározni, mennyi tesztelés elegendő. A túl kevés tesztelés azonban 
általánosabb probléma, mint a túl sok. Az, hogy a tervezéshez és megvalósításhoz viszo- 
nyítva pontosan mennyi erőforrást kell a tesztelésre kijelölni, természetesen függ a rendszer 
természetétől és a módszerektől, melyeket építéséhez használunk. Irányelvként javasolha- 
tom azonban, hogy időben, erőfeszítésben és tehetségben több erőforrást fordítsunk 
a rendszer tesztelésére, mint első változatának elkészítésére. A tesztelésnek olyan problé- 
mákra kell összpontosítania, melyeknek végzetes következményei lennének és olyanokra, 
melyek gyakran fordulnának elő. 


23.4.6. A programok , karbantartása" 

A , program-karbantartás" (software maintenance) helytelen elnevezés. A , karbantartás" szó 
félrevezető hasonlatot sugall a hardverrel. A programoknak nincs szükségük olajozásra, 
nincsenek mozgó alkatrészeik, amelyek kopnak, és nincsenek repedéseik, ahol a víz össze- 
gyűlik és rozsdásodást okoz. A szoftver pontosan lemásolható és percek alatt nagy távol- 
ságra átvihető. A szoftver nem hardver. 


Azok a tevékenységek, melyeket program-karbantartás néven emlegetünk, valójában az új- 
ratervezés és az újbóli megvalósítás, tehát a szokásos programfejlesztési folyamathoz tartoz- 
nak. Amikor a tervezésben hangsúlyosan szerepel a rugalmasság, bővíthetőség és hordoz- 
hatóság, közvetlenül a program fenntartásával kapcsolatos hibák hagyományos forrásaira 
összpontosítunk. 


A teszteléshez hasonlóan a karbantartás sem lehet utólagos megfontolás vagy a fejlesztés fő 
sodrától elválasztott tevékenység. Különösen fontos, hogy a projektben végig ugyanazok 
a személyek vegyenek részt, vagy legalábbis biztosítsuk a folytonosságot . Nem könnyű 
ugyanis , karbantartást" végeztetni egy olyan új (és általában kisebb tapasztalatú) emberek- 
ből álló csoporttal, akik az eredeti tervezőkkel és programozókkal nem állnak kapcsolat- 
ban. Ha mégis másoknak kell átadni a munkát, hangsúlyt kell fektetni arra, hogy az új em- 
berek tisztában legyenek a rendszer felépítésével és célkitűzéseivel. Ha a , karbantartó 
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személyzet" magára marad abban, hogy kitalálja a rendszer szerkezetét, vagy hogy a rend- 
szer összetevőinek célját megvalósításukból következtesse ki, a rendszer a helyi , foltozga- 
tás" hatására gyorsan degenerálódik. A dokumentáció nem segít, mert az inkább a részle- 
tek leírására való, nem pedig arra, hogy az új munkatársakat segítse a fő ötletek és elvek 


megértésében. 


23.4.7. Hatékonyság 


Donald Knuth megfigyelte, hogy ,az idő előtti optimalizálás a gyökere minden rossznak". 
Némelyek túlságosan megtanulták ezt a leckét és minden hatékonysági törekvést rossznak 
tekintenek, pedig a hatékonyságra végig ügyelni kell a tervezés és megvalósítás során. Ez 
azonban nem azt jelenti, hogy a tervezőnek minden , apróságot" hatékonnyá kell tennie, 
hanem csak azt, hogy az elsőrendű hatékonysági kérdésekkel foglalkoznia kell. 


A hatékonyság eléréséhez a legjobb módszer egy világos és egyszerű terv készítése. Csak 
egy ilyen terv maradhat viszonylag állandó a projekt élettartama alatt és szolgálhat a telje- 
sítmény behangolásának alapjául. Lényeges, hogy elkerüljük a nagy projekteket sújtó me- 
galomániát. Túl gyakori, hogy a programozók ,ha szükség lenne rá" tulajdonságokat 
(423.4.3.2, §23.5.3) építenek be, majd a , sallangok" támogatásával megkétszerezik, meg- 
négyszerezik a rendszerek méretét és futási idejét. Ennél is rosszabb, hogy az ilyen túlfino- 
mított rendszereket gyakran szükségtelenül nehéz elemezni, így nehéz lesz megkülönböz- 
tetni az elkerülhető túlterhelést az elkerülhetetlentől. Ez pedig még az alapvető elemzést és 
optimalizálást is akadályozza. Az optimum beállítása elemzés és teljesítménymérés eredmé- 
nye kell, hogy legyen, nem találomra piszmogás a kóddal. A nagy rendszerek esetében 
a tervezői vagy programozói , intuíció" különösen megbízhatatlan útmutató a hatékonysági 
kérdésekben. 


Fontos, hogy elkerüljük az eredendően rossz hatékonyságú szerkezeteket, illetve az olya- 
nokat, melyeknek elfogadható teljesítményszintre való optimalizálása sok időt és ügyessé- 
get kíván. Hasonlóképpen fontos, hogy csökkentsük az eredendően , hordozhatatlan" szer- 
kezetek és eszközök használatát, mert ez arra kárhoztatja a projektet, hogy régebbi (kisebb 
teljesítményű) vagy éppen drágább gépeken fusson. 
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23.5. Vezetés 


Feltéve, hogy legalább valamilyen értelme van, a legtöbb ember azt teszi, amire ráveszik. 
Nevezetesen, ha egy projekttel összefüggésben bizonyos , működési módokat" díjazunk és 
másokat büntetünk, csak kivételes programozók és tervezők fogják kockáztatni a karrierjü- 
ket, hogy azt tegyék, amit helyesnek tartanak, a vezetés ellenvéleményével, közönyével és 
bürokráciájával szemben?.? Ebből következik, hogy a cégnek kell, hogy legyen egy jutalma- 
zási rendszere, mely megfelel az általa megállapított tervezési és programozási célkitűzé- 
seknek. Mindazonáltal gyakran nem ez a helyzet: a programozási stílusban nagy változás 
csak a tervezési stílus megfelelő módosításával érhető el és ahhoz, hogy hatásos legyen, ál- 
talában mindkettő a vezetési stílus megváltoztatását igényli. A szellemi és szervezeti tehe- 
tetlenség könnyen eredményezhet olyan helyi változtatásokat, melyeket nem támogatnak 
a sikerét biztosító globális változtatások. Meglehetősen jellemző példa egy objektum- 
orientált programozást támogató nyelvre (mondjuk a C----ra) való átállás, a nyelv lehetősé- 
geit kihasználó megfelelő tervezési stratégiabeli változtatás nélkül, vagy éppen fordítva, 
, objektumorientált tervezésre" váltás azt támogató programozási nyelv bevezetése nélkül. 


23.5.1. Újrahasznosítás 


A kódok és tervek újrahasznosítását gyakran emlegetik, mint fő okot egy új programozási 
nyelv vagy tervezési módszer bevezetésére. A legtöbb szervezet azonban azokat az egyé- 
neket támogatja, akik a melegvíz újrafeltalálását választják. Például ha egy programozó tel- 
jesítnényét kódsorokban mérik; vajon kis programokat fog írni a standard könyvtárakra tá- 
maszkodva, bevételének és esetleg státuszának rovására? És ha egy vezetőt a csoportjában 
lévő emberek számával arányosan fizetnek, vajon fel fogja-e használni a mások által készí- 
tett programot, ha helyette a saját csoportjába újabb embereket vehet fel? Vagy ha egy cég- 
nek odaítélnek egy kormányszerződést, ahol a profit a fejlesztési költségeknek egy rögzí- 
tett százaléka, vajon ez a cég közvetetten csökkenteni fogja-e a profitját a leghatékonyabb 
fejlesztőeszközök használatával? Az újrahasznosítást nehéz jutalmazni, de ha a vezetés nem 
talál módot az ösztönzésére és jutalmazására, nem lesz újrahasznosítás. Az újrahasznosítás- 
nak más vonatkozásai is vannak. Akkor használhatjuk fel valaki más programját, ha: 


1. Működik: ahhoz, hogy újrahasznosítható legyen, a programnak előbb használ- 
hatónak kell bizonyulnia. 





3 Az olyan szervezetnek, mely a programozóival úgy bánik, mint az idiótákkal, hamarosan olyan programozói 


lesznek, akik csak idiótaként akarnak és képesek cselekedni. 
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2. Áttekinthető: fontos a program szerkezete, a megjegyzések, a dokumentáció és 
az oktatóanyag. 

3. Együtt létezhet egy olyan programmal, melyet nem kimondottan a vele való 
együttműködésre írtak. 

4. Támogatott (vagy magunk akarjuk támogatni; én általában nem akarom). 

5. Gazdaságos (megoszthatom-e más felhasználókkal a fejlesztési és karbantartási 
költségeket?). 

6. Meg lehet találni. 


Ehhez hozzátehetjük, hogy egy összetevő nem újrahasznosítható, amíg nincs valaki, aki 
, újra felhasználta". Egy összetevő valamely környezetbe beillesztése jellemzően működésé- 
nek finomításával, viselkedésének általánosításával és más programokkal való együttműkö- 
dési képességének javításával jár együtt. Amíg legalább egyszer el nem végeztük ezt 
a feladatot, még a leggondosabban megtervezett és elkészített összetevőknek is lehetnek 
szándékolatlan és váratlan egyenetlenségei. 


Az a tapasztalatom, hogy az újrahasznosításnak csak akkor vannak meg a szükséges feltét- 
elei, ha valaki közös ügynek tekinti, hogy ilyen munkamegosztás működjön. Egy kis cso- 
portban ez általában azt jelenti, hogy valaki — tervezetten vagy véletlenül — a közös könyv- 
tárak és dokumentáció gazdája lesz, egy nagyobb cégnél pedig azt, hogy megbíznak egy 
csoportot vagy osztályt, hogy gyűjtse össze, készítse el, dokumentálja, népszerűsítse és 
, tartsa karban" a több csoport által felhasznált programösszetevőket. Nem lehet túlbecsül- 
ni a szabványos összetevőkkel" foglalkozó csoport fontosságát. Vegyük észre, hogy egy 
program azt a közösséget tükrözi, amely létrehozta. Ha a közösségnek nincs együttműkö- 
dést és munkamegosztást elősegítő és jutalmazó rendszere, ritkán lesz együttműködés és 
munkamegosztás. A szabványos összetevőkkel foglalkozó csoport aktívan kell, hogy nép- 
szerűsítse ezeket az összetevőket. Ebből következik, hogy a jól megírt dokumentáció nél- 
külözhetetlen, de nem elegendő. A csoportnak ezen kívül gondoskodnia kell oktatóanya- 
gokról és minden más információról is, ami lehetővé teszi, hogy a reménybeli felhasználó 
megtaláljon egy összetevőt és megértse, miért segíthet az neki. Ennek következménye, 
hogy a piackutatással és az oktatással kapcsolatos tevékenységeket ennek a csoportnak kell 
vállalnia. 


Ha lehetséges, e csoport tagjainak szorosan együtt kell működniük az alkalmazásfejlesztők- 
kel. Csak így tudnak megfelelően értesülni a felhasználók igényeiről és felhívni a figyelmet 
az alkalmakra, amikor egyes összetevőket különböző programok közösen használhatnak. 
Ezzel amellett érvelek, hogy az ilyen csoportoknak legyen vélemény-nyilvánítási és tanács- 


adói szerepe, és hogy működjenek a belső kapcsolatok a csoportba bejövő és onnan kime- 
nő információ átvitelére. 
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Az ,komponens-csoport" sikerét az ügyfelek sikerével kell mérni. Ha a sikert egyszerűen 
azzal mérjük, hogy mennyi eszközt és szolgáltatást tudnak elfogadtatni a fejlesztő cégekkel, 
az ilyen csoport kereskedelmi ügynökké alacsonyodik és állandóan változó hóbortok elő- 
mozdítója lesz. 


vág 1) 


Nem minden kódnak kell újrahasznosíthatónak lennie, ez nem , mindenható" tulajdonság. 
Ha azt mondjuk, hogy egy összetevő , újrahasznosítható", ez azt jelenti, hogy felhasználása 
bizonyos kereteken belül kevés vagy semmi munkát nem igényel. A legtöbb esetben egy 
más vázba történő átköltöztetés jelentős munkával jár. Ebből a szempontból az újrahaszno- 
sítás erősen emlékeztet a hordozhatóságra (vagyis más rendszerre való átültetésre). Fontos 
megjegyezni, hogy az újrahasznosítás az ezt célzó tervezésnek, az összetevők tapasztalat 
alapján való finomításának és annak a szándékos erőfeszítésnek az eredménye, hogy már 
létező összetevőket keressünk (újbóli felhasználásra. Az újrahasznosítás nem az egyes 
nyelvi tulajdonságok vagy kódolási módszerek véletlenszerű használatából keletkezik, 
mintegy csodaként. A C---- olyan szolgáltatásai, mint az osztályok, a virtuális függvények és 
a sablonok lehetővé teszik, hogy a tervezés kifejezésmódja az újrahasznosítást könnyebbé 
Cés ezáltal valószínűbbé) tegye, de önmagukban nem biztosítják azt. 


23.5.2. Méret és egyensúly 


Az önálló vagy közösségben dolgozó programozót sokszor arra kényszerítik, hogy dolgát 
,a megfelelő módon" végezze. Intézményes felállásban ez gyakran így hangzik: ,a megfe- 
lelő eljárások kifejlesztése és szigorú követése szükséges". Mindkét esetben elsőként a jó- 
zan ész eshet áldozatul annak a kívánságnak, hogy mindenáron javítsunk ,a dolgok végzé- 
sének" módján. Sajnos, ha egyszer hiányzik a józan ész, az akaratlanul okozható károknak 
nincs határa. 


Vegyük a fejlesztési folyamat §23.4-ben felsorolt szakaszait és a §23.4.3-ban felsorolt terve- 
zési lépéseket. E lépésekből viszonylag könnyen kidolgozható egy megfelelő tervezési 
módszer, ahol minden szakasz pontosan körülhatárolt, meghatározott , bemenete és kime- 
nete" van, valamint rendelkezik az ezek kifejezéséhez szükséges, részben formális jelölés- 
móddal. Ellenőrző listákkal biztosíthatjuk, hogy a tervezési módszer következetesen támo- 
gassa a nagy számú eljárási és jelölésbeli szabály érvényre juttatását, és hogy ehhez 
eszközöket lehessen kifejleszteni. Továbbá, az összefüggések §24.3-ban bemutatott osztá- 
lyozását nézve valaki kinyilatkoztathatná, hogy bizonyos kapcsolatok jók, mások pedig 
rosszak, és elemző eszközöket adna annak biztosítására, hogy ezeket az értékítéleteket az 
adott projekten belül egységesen alkalmazzák. A programfejlesztési folyamat e , megerősí- 
tését" tökélyre fejlesztendő, valaki leírhatná a dokumentálás szabályait (beleértve a helyes- 


írási, nyelvtani és gépelési szabályoka0) és a kód általános küllemére vonatkozó előírásokat 
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(beleértve azt is, mely nyelvi tulajdonságokat és könyvtárakat szabad és melyeket nem sza- 
bad használni, hol használható behúzás, hogyan lehet elnevezni a függvényeket, változó- 
kat és típusokat stb.). 


Ezek között akad olyan, amely elősegítheti a sikert. Természetesen ostobaság lenne egy 
esetleg tízmillió kódsorból álló rendszer tervezését elkezdeni — melyet több száz ember fej- 
lesztene és több ezer ember , tartana karban" és támogatna tíz vagy még több évig — egy be- 
csületesen kidolgozott és meglehetősen szilárd váz nélkül. 


Szerencsére a legtöbb program nem ebbe a kategóriába esik. Ha azonban egyszer elfogad- 
tuk, hogy egy ilyen tervezési módszer vagy egy ilyen kódolási és dokumentálási szabvány- 
gyűjteményhez való ragaszkodás ,a helyes út", kötelező lesz annak általános és minden 
részletre kiterjedő használata. Ez kis programoknál nevetséges korlátozásokhoz és többlet- 
munkához vezethet: a haladás és siker mértékét jelentő hatékony munka helyett aktatolo- 
gatás és űrlaptöltögetés folyik majd. Ha ez történik, az igazi tervezők és programozók tá- 
vozni fognak és bürokraták lépnek a helyükbe. 


Ha egy közösségen belül már előfordult, hogy egy tervezési módszert ilyen nevetségesen 
rosszul alkalmaztak, annak sikertelensége ürügyet szolgáltat arra, hogy elkerüljenek szinte 
minden szabályozást a fejlesztési folyamatban. Ez viszont éppen olyan zűrzavarhoz és bal- 
sikerekhez vezet, mint amilyeneket az új tervezési módszer kialakításával meg akartunk 
előzni. 


Az igazi probléma megtalálni az egyensúlyt a megfelelő fokú szabályozás és az adott prog- 
ram fejlesztéséhez szükséges szabadság között. Ne higgyük, hogy erre a problémára 
könnyű lesz megoldást találni. Lényegében minden megközelítés csak kis projekteknél mű- 
ködik, pontosabban —ami még rosszabb, hiszen a rendszer rosszul tervezett és kegyetlen 
a belevont egyénekkel szemben - nagy projekteknél is, feltéve, hogy szemérmetlenül sok 
időt és pénzt akarunk elpocsékolni a problémára. 


Minden programfejlesztői munka kulcsproblémája, hogyan tartsuk magunkat a terv erede- 
ti szempontjaihoz. Ez a probléma a mérettel hatványozottan növekszik. Csak egy önálló 
programozó vagy egy kis csoport tudja szilárdan kézbentartani és betartani egy nagyobb 
munka átfogó célkitűzéseit. A legtöbb embernek olyan sok időt kell töltenie részprojektek- 
kel, technikai részletkérdésekkel, napi adminisztrációval stb., hogy az átfogó célok 
könnyen feledésbe merülnek vagy alárendelődnek helyi és közvetlenebb céloknak. Az is 
sikertelenséghez vezet, ha nincs egy egyén vagy egy csoport, melynek kizárólag az a fel- 
adata, hogy fenntartsa a terv sértetlenségét. Recept a siker ellen, ha egy ilyen egyénnek 
vagy csoportnak nem engedjük, hogy a munka egészére hasson. 
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Egy ésszerű hosszú távú célkitűzés hiánya károsabb, mint bármilyen egyedi tulajdonság hi- 
ánya. Egy ilyen átfogó célkitűzés megfogalmazása, észben tartása, az átfogó tervdokumen- 
táció megírása, a fő fogalmak ismertetése, és általában másokat segíteni, hogy észben tart- 
sák az átfogó célt, kis számú egyén feladata kell, hogy legyen. 


23.5.3. Egyének 


Az itt leírtak szerinti tervezés jutalom a tehetséges tervezők és programozók számára, vi- 
szont a sikerhez elengedhetetlen, hogy ezeket a tervezőket és programozókat megtaláljuk. 


A vezetők gyakran elfelejtik, hogy a szervezetek egyénekből állnak. Népszerű vélemény, 
hogy a programozók egyformák és csereszabatosak. Ez téveszme, mely tönkreteheti a kö- 
zösséget, azáltal, hogy elzavarja a leghatékonyabb egyéneket és még a megmaradtakat is 
arra ítéli, hogy jóval a képességeik alatti szinten dolgozzanak. Az egyének csak akkor fel- 
cserélhetők, ha nem engedjük, hogy hasznosítsák azokat a képességeiket, melyek a kérdé- 
ses feladat által megkövetelt minimum fölé emelik őket. A csereszabatosság elve tehát nem 
humánus és eredendően pazarló. 


A legtöbb programozási teljesítménymérés ösztönzi a pazarlást és kihagyja a számításból az 
egyéni hozzájárulást. A legkézenfekvőbb példa az a viszonylag elterjedt gyakorlat, hogy 
a haladást a megírt kódsorok, a dokumentáció lapjainak, vagy az elvégzett tesztek számá- 
val mérik. Az ilyen számok jól mutatnak diagramokon, de a valósághoz vajmi kevés közük 
van. Például, ha a termelékenységet a kódsorok számával mérjük, akkor egy összetevő si- 
keres újrahasznosítása negatív programozói teljesítnénynek minősülhet. Egy nagy prog- 
ramrész újratervezésénél a legjobb elvek sikeres alkalmazása ugyanilyen hatású. 


A teljesített munka minőségét sokkal nehezebb mérni, mint a , kimenet" mennyiségét, az 
egyéneket és csoportokat viszont a munka minősége alapján kell jutalmazni, nem durva 
mennyiségmérés alapján. Sajnos a minőség gyakorlati mérése — legjobb tudásom sze- 
rint — gyerekcipőben jár. Ezenkívül azon teljesítmény-előírások, melyek a munkának csak 
egy szakaszára vonatkoznak, hajlamosak befolyásolni a fejlesztést. Az emberek alkalmaz- 
kodnak a helyi határidőkhöz és az egyéni és csoportteljesítményt a kvóták által előírthoz 
igazítják. Ezt közvetlenül a rendszer átfogó épsége és teljesítménye szenvedi meg. Ha egy 
határidőt például az eltávolított vagy a megmaradt programhibákkal határoznak meg, belát- 
hatjuk, hogy a határidő csak a futási idejű teljesítmény figyelmen kívül hagyásával vagy 
a rendszer futtatásához szükséges hardver-erőforrások optimalizálásának mellőzésével lesz 
tartható. Ellenben ha csak a futási idejű teljesítményt mérjük, a hibaarány biztosan növeked- 
ni fog, amikor a fejlesztők a rendszert a futási teljesítményt mérő programokra igyekeznek 


optimalizálni. Az értelmes minőségi előírások hiánya nagy követelményeket támaszt a ve- 


968 lervezés a C-t segítségével 


zetők szakértelmével szemben, de az alternatíva az, hogy a haladás helyett egyes találom- 
ra kiválasztott tevékenységeket fognak jutalmazni. Ne feledjük, hogy a vezetők is emberek. 
Nekik is legalább annyi oktatásra van szükségük, mint az általuk vezetetteknek. Mint 
a programfejlesztés más területein, itt is hosszabb távra kell terveznünk. Lényegében lehe- 
tetlen megítélni egy egyén teljesítményét egyetlen év munkája alapján. A következetesen és 
hosszú távon vezetett feljegyzések azonban megbízható előrejelzést biztosítanak az egyes 
munkatársak teljesítményével kapcsolatban és hasznos segítséget adnak a közvetlen múlt 
értékeléséhez. Az ilyen feljegyzések figyelmen kívül hagyása — ahogy akkor történik, ami- 
kor az egyéneket pusztán cserélhető fogaskeréknek tekintik a szervezet gépezeté- 
ben - a vezetőket kiszolgáltatja a félrevezető mennyiségi méréseknek. 


A hosszú távra tervezés egyik következménye, hogy az egyének (mind a fejlesztők, mind 
a vezetők) az igényesebb és érdekesebb feladatokhoz hosszabb időt igényelnek. Ez elveszi 
a kedvét az állásváltoztatóknak éppúgy, mint a , karriercsinálás" 
tóknak. Törekedni kell arra, hogy kicsi legyen a fluktuáció mind a műszakiak, mind a kulcs- 
fontosságú vezetők körében. Egyetlen vezető sem lehet sikeres a kulcsemberekkel való 
egyetértés és friss, a tárgyra vonatkozó technikai tudás nélkül, de ugyanígy egyetlen terve- 
zőkből és fejlesztőkből álló csoport sem lehet hosszú távon sikeres alkalmas vezetők támo- 
gatása nélkül és anélkül, hogy alapjaiban értsék azt a környezetet, melyben dolgoznak. 


miatt munkakört változta- 


Ahol szükséges az innováció, az idősebb szakemberek, elemzők, tervezők, programozók 
stb. létfontosságú szerepet játszanak az új eljárások bevezetésében. Ők azok, akiknek új 
módszereket kell megtanulniuk és sok esetben el kell felejteniük a régi szokásokat, ami 
nem könnyű, hiszen általában komoly erőfeszítéseket tettek a régi munkamódszerek elsa- 
játítására, ráadásul az e módszerekkel elért sikereikre, szakmai tekintélyükre támaszkod- 
nak. Sok szakmai vezetővel ugyanez a helyzet. 


Természetesen az ilyen egyének gyakran félnek a változástól. Ezért a változással járó prob- 
lémákat túlbecsülik és nehezen ismerik el a régi módszerekkel kapcsolatos problémákat. 
Ugyanilyen természetes, hogy a változás mellett érvelők hajlamosak túlbecsülni az új mód- 
szerek előnyeit és alábecsülni a változással járó problémákat. A két csoportnak kommuni- 
kálnia kell: meg kell tanulniuk ugyanazon a nyelven beszélni és segíteniük kell egymásnak, 
hogy az átmenetre megfelelő módszert dolgozhassanak ki. Ha ez nem történik meg, a szer- 
vezet megbénul és a legjobb képességű egyének távoznak mindkét csoportból. Mindkét 
csoportnak emlékeznie kell arra, hogy a legsikeresebb , öregek" gyakran azok, akik tavaly 
az ,ifjú titánok" voltak. Ha adott az esély arra, hogy megalázkodás nélkül tanuljanak, 
a tapasztaltabb programozók és tervezők lehetnek a legsikeresebb és legnagyobb betekin- 
téssel rendelkező hívei a változtatásnak. Egészséges szkepticizmusuk, a felhasználók isme- 
rete és a szervezet működésével kapcsolatban szerzett tapasztalataik felbecsülhetetlenül 
értékesek lehetnek. Az azonnali és gyökeres változások javaslói észre kell vegyék, hogy az 
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átmenet, amely az új eljárások fokozatos elsajátításával jár, többnyire elengedhetetlen. 
Azoknak viszont, akik nem kívánnak változtatni, olyan területeket kell keresniük, ahol nem 
szükséges változtatni, nem pedig dühös hátvédharcot vívni olyan területeken, ahol az új kö- 
vetelmények már jelentősen megváltoztatták a siker feltételeit. 


23.5.4. Hibrid tervezés 


Új munkamódszerek bevezetése egy cégnél fáradságos lehet. Jelentős törést okozhat mind 
a szervezetben, mind az egyénekben. Egy váratlan változás, mely a , régi iskola" hatékony 
és tapasztalt tagjait egyik napról a másikra az , új iskola" zöldfülű újoncaivá változtatja, álta- 
lában elfogadhatatlan. Változások nélkül azonban ritkán érhetünk el nagy nyereséget, a je- 
lentős változások pedig többnyire kockázattal járnak. 


A C44-t úgy tervezték, hogy a kockázatot a lehető legkisebbre csökkentse, azáltal, hogy 
lehetővé teszi a módszerek fokozatos elsajátítását. Bár világos, hogy a C-- használatának 
legnagyobb előnyei az elvont adatábrázolásból és az objektumorientált szemléletből adód- 
nak, nem biztos, hogy e nyereségeket a leggyorsabban a múlttal való gyökeres szakítással 
lehet elérni. Egyszer-egyszer keresztülvihető az ilyen egyértelmű szakítás, de gyakoribb, 
hogy a javítás vágyát egy időre félre kell tennünk, hogy meggondoljuk, hogyan kezeljük az 
átmenetet. A következőket kell figyelembe vennünk: 


A tervezőknek és programozóknak idő kell az új szakismeretek megszerzéséhez. 
Az új kódnak együtt kell működnie a régi kóddal. 

A régi kódot karban kell tartani (gyakran a végtelenségig). 

A létező terveket és programokat be kell fejezni (időre). 

Az új eljárásokat támogató eszközöket be kell vezetni az adott környezetbe. 


....]... 


Ezek a tényezők természetesen hibrid (kevert) tervezési stílushoz vezetnek — még ott is, 
ahol némelyik tervezőnek nem ez a szándéka. Az első két pontot könnyű alulértékelni. 


Azáltal, hogy számos programozási irányelvet támogat, a C-t- változatos módon támogatja 
a nyelv használatának fokozatos bevezetését: 


6 A programozók produktívak maradhatnak a C-- tanulása közben. 

6 AC-t- jelentős előnyöket nyújt egy eszközszegény környezetben. 

6 ACt4-4 programrészek jól együttműködnek a C-ben vagy más hagyományos 
nyelven írt kóddal. 

6 A C---nak jelentős , C-kompatibilis" részhalmaza van. 
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Az alapötlet az, hogy a programozók egy hagyományos nyelvről úgy térhetnek át a C----ra, 
hogy a nyelvre áttérve először még megtartják a hagyományos (eljárásközpontú) progra- 
mozási stílust, azután használni kezdik az elvont adatábrázolás módszereit, végül — amikor 
már elsajátították a nyelvet és a hozzá tartozó eszközök használatát — áttérnek az objektum- 
orientált (object-oriented) és az általánosított programozásra (generic programming). Egy 
jól tervezett könyvtárat sokkal könnyebb használni, mint megtervezni és elkészíteni, így 
egy kezdő már az előrehaladás korai szakaszaiban is részesülhet az elvont ábrázolás hasz- 
nálatának előnyeiből. 


Az objektumorientált tervezést és programozást, valamint a C$-4 fokozatosan történő meg- 
tanulását támogatják azok a szolgáltatások, melyekkel a C-- kódot keverhetjük olyan 
nyelveken írt kóddal, melyek nem támogatják a C-t- elvont adatábrázolási és objektum- 
orientált programozási fogalmait (424.2.19. Sok felület eljárásközpontú maradhat, mivel 
nincs közvetlen haszna, ha valamit bonyolultabbá teszünk. Sok kulcsfontosságú könyvtár- 
nál az átültetést már elvégezte a könyvtár létrehozója, így a Ct- programozónak nem kell 
tudnia, mi a tényleges megvalósítás nyelve. A C-ben vagy hasonló nyelven írt könyvtárak 
használata az újrahasznosítás elsődleges és kezdetben legfontosabb formája a C---ban. 


A következő lépés — melyet csak akkor kell elvégezni, amikor ténylegesen szükség van a ki- 
finomultabb eljárásokra — a C, Fortran vagy hasonló nyelven írt szolgáltatások osztályok for- 
májában való , tálalása", az adatszerkezetek és függvények C-- nyelvű felületosztályokba 
zárása által. Egy egyszerű példa a jelentés bővítésére az , eljárás és adatszerkezet" szintjéről 
az elvont adatábrázolás szintjére a §11.12 string osztálya. Itt a C karakterlánc-ábrázolását és 
szabványos karakterlánc-függvényeit használjuk fel egy sokkal egyszerűbben használható 
karakterlánc-típus létrehozására. 


Hasonló módszer használható egy beépített vagy egyedi típusnak egy osztályhierarchiába 
illesztésére (423.5.19. Ez lehetővé teszi, hogy a C-ra készült terveket az elvont adatábrá- 
zolás és az osztályhierarchiák használatához továbbfejlesszük még olyan nyelveken írt kód 
jelenlétében is, ahonnan hiányoznak ezek a fogalmak, sőt azzal a megszorítással is, hogy az 
eredményül kapott kód eljárásközpontú nyelvekből is meghívható legyen. 
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23.6. Jegyzetek 


Ez a fejezet csak érintette a programozás tervezési és vezetési kérdéseit A további tanulmá- 
nyokat segítendő összegyűjtöttünk egy rövid irodalomjegyzéket. Részletesebbet [Booch, 
19941] alatt találunk. 


[Anderson, 1990] 


[Booch, 1994] 


[Booch, 1996] 


[Brooks, 1982] 


ÍBrooks, 1987] 


[Coplien, 1995] 


[De Marco, 1987] 


[Gamma, 1994] 


[Jacobson, 1992] 


Bruce Anderson és Sanjiv Gossain: An Iterative Design Model for Reusable Object- 
Oriented Software. Proc. OOPSLA 90. Ottawa, Canada. Egy tervező és újratervező 
modell leírása, példákkal és a tapasztalatok tárgyalásával. 

Grady Booch: Object-Oriented Analysis and Design with Applications. 
Benjamin/Cummings. 1994. ISBN 0-8053-5340-2. Részletes leírást tartalmaz a terve- 
zésről, és egy grafikai jelölésmóddal támogatott tervezési módról. Számos nagyobb 
tervezési példa áll rendelkezésre C4- nyelven. Kiváló könyv, melyből e fejezet is 
sokat merített. Az e fejezetben érintett kérdések jó részét nagyobb mélységben 
tárgyalja. 

Grady Booch: Object Solutions. Benjamin/Cummings. 1996. ISBN 0-8053-0594-7. 
Az objektumközpontú rendszerek fejlesztését a vezetés szemszögéből vizsgálja. 
Számos C--- példát tartalmaz. 

Fred Brooks: 7he Mythical man Month. Addison-Wesley. 1982. Ezt a könyvet min- 
denkinek pár évente újra el kellene olvasnia! Intés a nagyképűség ellen. Technika- 
ilag kissé eljárt felette az idő, de az emberi, szervezeti és méretezési vonatkozásai 
időtállóak. 1997-ben kibővítve újra kiadták. ISBN 1-201-83595-9. 

Fred Brooks: No Silver Bullet. IEEE Computer. Vol 20. No. 4. 1987 április. A nagy- 
bani szoftverfejlesztés megközelítéseinek összegzése, a régóta aktuális figyelmez- 
tetéssel: nincsenek csodaszerek (, nincs ezüstgolyó"). 

James O. Coplien és Douglas C. Schmidt (szerk.): Pattern Languages of Program 
Design. Addison-Wesley. 1995. ISBN 1-201-60734-4. 

T. DeMarco és T. Lister: Peopleware. Dorset House Publishing Co. 1987. Azon ritka 
könyvek egyike, melyek az egyénnek a programfejlesztésben betöltött szerepével 
foglalkoznak. Vezetőknek kötelező, kellemes esti olvasmány, számos ostoba hiba 
ellenszerét tartalmazza. 

Eric Gamma és mások: Design Patterns. Addison-Wesley. 1994. ISBN 0-201-63361- 
2. Gyakorlati katalógus, mely rugalmas és újrahasznosítható programok készítési 
módszereit tartalmazza, bonyolultabb, jól kifejtett példákkal. Számos C--- példát 
tartalmaz. 

Ivar Jacobson és mások: Object-Oriented Software Engineering. Addison-Wesley. 
1992. ISBN 0-201-54435-0. Alapos és gyakorlati leírás, amely használati esetek (use 
case, §23.4.3.1) alkalmazásával írja le a szoftverfejlesztést ipari környezetben. Fél- 


reérti a Ct-t nyelvet, 10 évvel ezelőtti állapotával leírva. 
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IKerr, 1987] 


(ILiskov, 1987] 


[Martin, 1995] 


(Meyer, 1988] 


IParkinson, 1957] 


IShlaer, 1988] 


ISnyder, 1986] 


Ron Kerr: A Materialistic View of the Software "Engineering" Analogy. SIGPLAN 
Notices, 1987 március. Az ebben és a következő fejezetekben használt hasonlatok 
nagyban építenek e cikkre és a Ron által tartott bemutatókra, illetve vele folytatott 
beszélgetésekre. 

Barbara Liskov: Data Abstraction and Hierarchy. Proc. OOPSLA "87 (Függelék). 
Orlando, Florida. Az öröklődés szerepe az elvont adatábrázolásban. Megjegyzen- 
dő, hogy a Cst számos eszközt biztosít a felvetett problémák többségének megol- 
dására (424.3.4). 

Robert C. Martin: Designing Object-Oriented C-- Applications Using the Booch 
Method. Prentice-Hall. 1995. ISBN 0-13-203837-4. Rendszerezetten mutatja be, ho- 
gyan jutunk el a problémától a C-t kódig. Lehetséges tervezési módokat és a köz- 
tük való döntés elveit ismerteti. A többi tervezéssel foglalkozó könyvnél gyakorla- 
tiasabb és konkrétabb. Számos C--- példát tartalmaz. 

Bertrand Meyer: Object Oriented Software Construction. Prentice Hall. 1988. Az 1-64. 
és 323-334. oldalakon jó bevezetést ad az objektumközpontú programozás és terve- 
zés egy nézetéről, számos használható gyakorlati tanáccsal. A könyv maradék része 
az Eiffel nyelvet írja le. Hajlamos az Eiffelt és az általános elveket összekeverni. 

C. N. Parkinson: Parkinson s Law and other Studies in Administration. Houghton 
Mifflin. Boston. 1957. Az egyik leghumorosabb és legpontosabb leírás, melyet a bü- 
rokráciáról írtak. 

S. Shlaer és S. J. Mellor: Object-Oriented Systems Analysis és Object Lifecycles. 
Yourdon Press. ISBN 0-13-629023-X és 0-13-629940-7. Az elemzés, tervezés és 
programozás egy olyan szemléletét mutatja be, mely jelentősen eltér az itt bemuta- 
tottól és a Ct- által támogatottól. 

Alan Snyder: Encapsulation and Inheritance in Object-Oriented Programming 
Languages. Proc. OOPSLA"86. Portland, Oregon. Valószínűleg a betokozás 
(enkapszuláció) és öröklődés kapcsolatának első jó leírása. A többszörös öröklő- 


dést ugyancsak tárgyalja. 


(Wirfs-Brock, 1990] Rebecca Wirfs-Brock, Brian Wilkerson és Lauren Wiener: Designing Object- 


Oriented Software. Prentice Hall. 1990. Szerepmintákon alapuló emberközpontú 
tervezési módszertant ír le CRC kártyák használatával. A szöveg (talán a módszer- 


tan is) részrehajló a Smalltalk irányában. 
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23.7. Tanácsok 


[1] 
[2] 
[3] 
[4] 
[5] 
[6] 


[7] 
[8] 
[9] 
[10] 
[11] 
[12] 
[13] 


[14] 


[15] 
[16] 
[17] 
[18] 
[19] 
[20] 
[21] 
[22] 


[23] 
[24] 


[25] 


Legyünk tisztában vele, mit akarunk elérni. §23.3. 

Tartsuk észben, hogy a programfejlesztés emberi tevékenység. §23.2, 423.5.3. 
Hasonlat által bizonyítani ámítás. §23.2. 

Legyenek meghatározott, kézzelfogható céljaink. §23.4. 

Ne próbáljunk emberi problémákat technikai megoldásokkal orvosolni. §23.4. 
Tekintsünk hosszabb távra a tervezésben és az emberekkel való bánásmódban. 
423.4.1, §23.5.3. 

Nincs méretbeli alsó határa azon programoknak, melyeknél értelme van a kó- 
dolás előtti tervezésnek. §23.2. 

Ösztönözzük a visszajelzést. §23.4. 

Ne cseréljük össze a tevékenységet a haladással. §23.3, 423.4. 

Ne általánosítsunk jobban, mint szükséges, mint amivel kapcsolatban közvetlen 
tapasztalataink vannak, és ami tesztelhető. §423.4.1, §23.4.2. 

Ábrázoljuk a fogalmakat osztályokként. §23.4.2, §23.4.3.1. 

A program bizonyos tulajdonságait nem szabad osztályként ábrázolni. §23.4.3.1. 
A fogalmak közötti hierarchikus kapcsolatokat ábrázoljuk osztályhierarchiák- 
ként. §23.4.3.1. 

Aktívan keressük a közös vonásokat az alkalmazás és a megvalósítás fogalmai- 
ban és az eredményül kapott általánosabb fogalmakat ábrázoljuk bázisosztá- 
lyokként. §23.4.3.1, §23.4.3.5. 

Máshol alkalmazott osztályozások nem szükségszerűen használhatóak egy 
program öröklési modelljében. §23.4.3.1. 

Az osztályhierarchiákat a viselkedés és a nem változó (invariáns) tulajdonságok 
alapján építsük fel. §23.4.3.1, §23.4.3.5, §24.3.7.1. 

Vizsgáljuk meg a használati eseteket. §23.4.3.1. 

Használjunk CRC kártyákat, ha szükséges. §23.4.3.1. 

Modellként, ösztönzésként és kiindulópontként használjunk létező rendszere- 
ket. §23.4.3.6. 

Óvakodjunk a rajzos tervezéstől. §23.4.3.1. 

Dobjuk el a prototípust, mielőtt teherré válik. §23.4.4. 

Számoljunk a változtatás lehetőségével, összpontosítsunk a rugalmasságra, a bő- 
víthetőségre, a hordozhatóságra és az újrahasznosíthatóságra. §23.34.2. 

A középpontba az összetevők tervezését helyezzük. 423.4.3. 

A felületek az egyes fogalmakat egyetlen elvonatkoztatási szinten ábrázolják. 
423.4.3.1. 


A változtatás küszöbén tartsuk szem előtt a stabilitást. §23.4.2. 
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[26] 
[271 
128] 
[291 
[30] 
[31] 
[32] 
[33] 
[34] 
[35] 


[36] 
[371 
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A gyakran használt felületek legyenek kicsik, általánosak és elvontak, hogy az 
eredeti terv lényegét ne kelljen módosítani. §23.4.3.2, 423.4.3.5.. 

Törekedjünk a minimalizmusra. Ne használjunk , ha szükség lenne rá" tulajdon- 
ságokat. §423.4.3.2. 

Mindig vizsgáljuk meg egy osztály más lehetséges ábrázolásait. Ha nincs kézen- 
fekvő alternatíva, az osztály valószínűleg nem képvisel tiszta fogalmat. §23.4.3.4. 
Többször is vizsgáljuk felül és finomítsuk mind a tervezést, mind a megvalósítás 
módját. §23.4, §23.4.3. 

Használjuk az elérhető legjobb eszközöket a teszteléshez és a probléma, a terv, 
illetve a megvalósítás elemzéséhez. §23.3, §23.4.1, §23.4.4. 

Kísérletezzünk, elemezzünk és teszteljünk a lehető leghamarabb és leggyakrab- 
ban. §23.4.4, §23.4.5. 

Ne feledkezzünk meg a hatékonyságról. §23.4.7. 

Teremtsünk egyensúlyt a formalitások szintje és a projekt mérete között. §23.5.2. 
Mindenképpen bízzunk meg valakit, aki az átfogó tervezésért felel. §23.5.2. 
Dokumentáljuk, népszerűsítsük és támogassuk az újrahasznosítható összetevő- 
ket. §23.5.1. 

Dokumentáljuk a célokat és elveket éppúgy, mint a részleteket. §23.4.6. 
Gondoskodjunk oktatóanyagról az új fejlesztők részére a dokumentáció része- 
ként. $423.4.6. 


[38] Jutalmazzuk és ösztönözzük a tervek, könyvtárak és osztályok újrahasznosítását. 


$23.a.L 
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Tervezés és programozás 


, Legyen egyszerű: annyira egyszerű, 
amennyire csak lehet — de ne egyszerűbb." 
(A. Einstein) 


A tervezés és a programozási nyelv e Osztályok s Öröklés s Típusellenőrzés e 
Programozás s Mit ábrázolnak az osztályok? e Osztályhierarchiák e Függőségek e 
Tartalmazás e Tartalmazás és öröklés s Tervezési kompromisszumok e Használati kapcso- 
latok s , Beprogramozott" kapcsolatok "e Invariánsok s Hibaellenőrzés feltételezésekkel e 
Betokozás "e Komponensek e Sablonok "e Felület és megvalósítás e Tanácsok 


24.1. Áttekintés 


Ebben a fejezetben azt vizsgáljuk meg, hogy a programozási nyelvek -— és maga a C-t — ho- 
gyan támogatják a tervezést. 


§24.2 Az osztályok, osztályhierarchiák, a típusellenőrzés és maga a programo- 
zás alapvető szerepe 

424.3 Az osztályok és osztályhierarchiák használata, különös tekintettel a prog- 
ramrészek közötti függőségekre 
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§24.4 A komponens — mint a tervezés alapegysége — fogalma, és a felületek fel- 
építésére vonatkozó gyakorlati megfigyelések 


Az általánosabb tervezési kérdésekkel a 23. fejezetben foglalkoztunk, míg az osztályok kü- 
lönböző használati módjait részletesebben a 25. fejezet tárgyalja. 


24.2. A tervezés és a programozási nyelv 


Ha hidat szeretnénk építeni, figyelembe kellene vennünk az anyagot, amiből építjük. A híd 
tervezését erősen befolyásolná az anyag megválasztása és viszont. A kőhidakat másképp 
kell megtervezni, mint az acélhidakat vagy a fahidakat és így tovább. Nem lennénk képe- 
sek kiválasztani a hídhoz a megfelelő anyagot, ha nem tudnánk semmit a különböző anya- 
gokról és használatukról. Természetesen nem kell ácsmesternek lenni ahhoz, hogy valaki 
fahidat tervezzen, de ismernie kell a faszerkezetek alapelveit, hogy választani tudjon, fából 
vagy vasból építsen-e hidat. Továbbá — bár nem kell valakinek személyesen ácsmesternek 
lennie egy fahíd tervezéséhez - kell, hogy részletesen ismerje a fa tulajdonságait és az ácsok 
szokásait. 


Ehhez hasonlóan, ahhoz, hogy valamilyen programhoz nyelvet válasszunk, több nyelv 
ismerete szükséges, a program egyes részeinek sikeres megtervezéséhez pedig meglehető- 
sen részletesen kell ismernünk a megvalósításhoz választott nyelvet — még akkor is, ha sze- 
mélyesen egyetlen kódsort sem írunk. A jó hídtervező figyelembe veszi az anyagok tulaj- 
donságait és azok megfelelő felhasználásával növeli a terv értékét. A jó szoftvertervező 
ugyanígy a választott programozási nyelv erősségeire épít és — amennyire csak lehet — elke- 
rüli annak olyan használatát, ami problémákat okozhat a kód íróinak. 


Azt gondolhatnánk, hogy ez a nyelvi kérdések iránti érzékenység természetes, ha csak 
egyetlen tervezőt vagy programozót érint. Sajnos azonban még az önálló programozó is , kí- 
sértésbe" eshet, hogy a nyelvet — hiányos tapasztalata vagy gyökeresen eltérő nyelvekben 
kialakult programozási stílusa — miatt helytelenül használja. Amikor a tervező és a progra- 
mozó nem azonos - és különösen ha szakmai és kulturális hátterük különböző -, szinte bi- 


zonyos, hogy a program hibás, körülményes vagy nem hatékony lesz. 


Mit nyújthat tehát a programozási nyelv a tervezőnek? Olyan tulajdonságokat, melyek lehe- 
tővé teszik a terv alapfogalmainak közvetlen ábrázolását a programban. Ez megkönnyíti 
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a kód megírását, könnyebbé teszi a tervezés és megvalósítás közötti kölcsönös megfelelés 
fenntartását, javítja a tervezők és programozók közötti kapcsolattartást és jobb eszközök ké- 
szítését teszi lehetővé mindkét csoport támogatására. 


A legtöbb tervezési módszer a program különböző részei közti függőségekkel foglalkozik 
(rendszerint azért, hogy a lehető legkisebbre csökkentse számukat és biztosítsa, hogy a füg- 
gőségek pontosan meghatározottak és átláthatóak legyenek). Egy nyelv, mely támogatja 
a programrészek kapcsolatát biztosító felületeket, képes támogatni az ezekre épülő terve- 
zést is, illetve garantálni tudja, hogy ténylegesen csak az előre látott függőségek létezzenek. 
Mivel az ilyen nyelvekben sok függés közvetlenül a kódban is megjelenik, beszerezhetők 
olyan eszközök, melyek a programot olvasva függőségi diagramokat készítenek. Ez meg- 
könnyíti a tervezők és azok dolgát, akiknek szükségük van a program szerkezetének meg- 
értésére. Egy olyan programozási nyelv, mint a C-- felhasználható a terv és a program köz- 
ti szakadék kisebbítésére és a zavarok és félreértések körének következetes szűkítésére. 


A C44 legfontosabb fogalma az osztály. A C-t osztályai típusok. A névterekkel együtt az 
osztályok is az adatrejtés elsődleges eszközei. A programok felhasználói típusok hierarchi- 
áiként építhetők fel. Mind a beépített, mind a felhasználói típusok a statikusan ellenőrzött 
típusokra vonatkozó szabályoknak engedelmeskednek. A virtuális függvények ezen szabá- 
lyok megsértése nélkül a futási idejű kötésről gondoskodnak. A sablonok a paraméterezett 
típusok tervezését támogatják, a kivételek pedig szabályozottabb hibakezelésre adnak mó- 
dot. A C44 ezen szolgáltatásai anélkül használhatók, hogy többletterhet jelentenének a C 
programokhoz képest. Ezek a C-t-t azon elsőrendű tulajdonságai, melyeket a tervezőnek 
meg kell értenie és tekintetbe kell vennie. Ezenkívül a széles körben elérhető nagy prog- 
ramkönyvtárak — a mátrixkönyvtárak, adatbázis-felületek, a grafikus felhasználói felületek 
könyvtárai és a párhuzamosságot támogató könyvtárak -— is erősen befolyásolhatják a terve- 
zési döntéseket. 


Az újdonságtól való félelem néha a Ct-4 optimálisnál rosszabb felhasználásához vezet. 
A más nyelveknél, más rendszereken és alkalmazási területeken tanultak helytelen alkalma- 
zása ugyanezt eredményezi. A gyenge tervezőeszközök szintén elronthatják a terveket. Íme 
öt a leggyakrabban elkövetett — a nyelvi tulajdonságok rossz kihasználását és korlátozások 
felrúgását eredményező - tervezői hibák közül: 


1. Az osztályok figyelmen kívül hagyása és olyan tervezés, amely a programo- 
zókat arra kényszeríti, hogy csak a C részhalmazt használják. 

2. A wszármaztatott osztályok és virtuális függvények figyelmen kívül hagyása, 
csak az absztrakt adatábrázolási módszerek részhalmazának használata. 

3. A statikus típusellenőrzés figyelmen kívül hagyása és olyan tervezés, amely 
a programozókat arra kényszeríti, hogy utánozzák a dinamikus típusellenőrzést. 
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4. A programozás figyelmen kívül hagyása és a rendszer olyan megtervezése, 
amely a programozók kiküszöbölését célozza. 
5. Az osztályhierarchiák kivételével mindennek a figyelmen kívül hagyása. 


Ezeket a hibákat általában a következő háttérrel rendelkező tervezők követik el: 


1. akik korábban a C-vel, a hagyományos CASE eszközzel, vagy struktúrált ter- 
vezéssel foglalkoztak, 

2. akik korábban Ada83, Visual Basic vagy más absztrakt ábrázolást támogató 
nyelven dolgoztak, 

3. akik Smalltalk vagy Lisp múlttal rendelkeznek, 

akik nem műszaki vagy nagyon speciális területen dolgoztak, és 

5. akik olyan területről érkeztek, ahol erős hangsúlyt kapott a , tiszta" objektum- 
orientált programozás. 


tsai 


Mindegyik esetben kételkednünk kell, vajon jól választottákce meg a megvalósítás nyel- 
vét, a tervezési módszert, illetve hogy a tervező elsajátította-e a kezében lévő eszközök 
használatát. 


Nincs semmi szokatlan vagy szégyellni való az ilyen problémákban. Ezek egyszerűen olyan 
hiányosságok, amelyek nem optimális terveket eredményeznek és a programozókra feles- 
leges terheket hárítanak. A tervezők ugyanezekkel a problémákkal találják magukat szem- 
ben, ha a tervezési módszer fogalmi felépítése észrevehetően szegényesebb, mint a Ct--é. 
Ezért ahol lehetséges, kerüljük az ilyen hibákat. 


A következő fejtegetés ellenvetésekre adott válaszokból áll, mivel ez a valóságban is így 
szokott lenni. 


24.2.1. Az osztályok figyelmen kívül hagyása 


Vegyük azt a tervezést, amely figyelmen kívül hagyja az osztályokat. Az eredményül kapott 
C-44 program nagyjából egyenértékű az ugyanezen tervezési folyamat eredményeként kap- 
ható C programmal -— és ez a program ugyancsak nagyjából egyenértékű azzal a COBOL 
programmal, melyet ugyanezen tervezési folyamat eredményeként kapnánk. A tervezés lé- 
nyegében , programozási nyelvtől függetlenül" folyt, a programozót arra kényszerítve, hogy 
a C és a COBOL közös részhalmazában kódoljon. Ennek a megközelítésnek vannak elő- 
nyei. Például az adat és a kód szigorú elkülönítése, ami könnyűvé teszi az ilyen programok- 
hoz tervezett hagyományos adatbázisok használatát. Mivel egy , minimális" programozási 
nyelvet használunk, kevesebb tudást — vagy legalább is kevesebb féle tudást — követelünk 
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meg a programozóktól. Sok programnál — mondjuk egy hagyományos, szekvenciális adat- 


bázist frissítőnél — ez a gondolkodásmód egészen ésszetű, az évtizedek alatt kifejlesztett ha- 
gyományos eljárások pedig megfelelőek a feladathoz. 


Tegyük fel azonban, hogy a program a rekordokat (vagy karaktereke9) a hagyományos 
szekvenciális feldolgozástól eltérően kezeli, vagy bonyolultabb — mondjuk, egy interaktív 
CASE rendszerről van szó. Az absztrakt adatábrázolás nyelvi támogatásának hiánya, amit az 
osztályok elhanyagolása melletti döntés okoz, fájó lesz. Az eredendő bonyolultság az alkal- 
mazásban valahol meg fog mutatkozni, és ha a rendszert egy szegényes nyelven készítet- 
ték, a kód nem fogja a tervet közvetlenül tükrözni. A program kódja túl hosszú lesz, hiány- 
zik belőle a típusellenőrzés és általában nem megközelíthető segédeszközök számára. 
A program fenntartása és későbbi módosíthatósága szempontjából ez igazi rémálom. 


A problémára általános megoldás, ha eszközöket készítünk a tervezési módszer fogalmai- 
nak támogatására. Ezek az eszközök magasabb szintű építkezést és ellenőrzést tesznek le- 
hetővé, ami ellensúlyozza a (szándékosan legyengítet9) programozási nyelv gyengeségét. 
A tervezési módszer tehát egy egyedi célú (és általában testületi tulajdont képező) progra- 
mozási nyelvvé válik. Az ilyen programozási nyelvek legtöbb esetben csak gyenge pótlékai 


a széles körben elérhető általános célú programozási nyelveknek, melyeket hozzájuk való 
tervezőeszközök támogatnak. 


Az osztályok tervezésből való kihagyásának legáltalánosabb oka egyszerűen a tehetetlen- 
ség. A hagyományos programozási nyelvek nem támogatják az osztály fogalmát, a hagyo- 
mányos tervezési módszerek pedig tükrözik ezt a gyengeséget. A tervezés legtöbbször 
a problémák eljárásokra bontására összpontosul, melyek a kívánt műveleteket hajtják vég- 
re. Ezt a 2. fejezetben eljárásközpontú (procedurális) programozásnak nevezett fogalmat 
a tervezéssel összefüggésben általában funkcionális (függvényekre vagy műveletekre való) 
lebontásnak (functional decomposition) nevezzük. Gyakori kérdés, hogy , tudjuk-e hasz- 
nálni a C-t egy funkcionális lebontáson alapuló tervezési módszerrel együtt?" A válasz 
igen, de a legvalószínűbb, hogy a C4--t végül egyszerűen csak mint egy jobb C-t fogjuk 
használni és a fentebb említett problémákkal fogunk kínlódni. Átmeneti időszakban, már 
befejezett tervezésnél, vagy olyan alrendszereknél, ahol (a bevont személyek tapasztalatát 
figyelembe véve) nem várható, hogy az osztályok jelentős előnnyel járnak, ez elfogadható. 
Hosszabb távon és általában azonban az osztályok használatának -— a funkcionális lebontás- 
ból következő - ellenzése nem összeegyeztethető a C4- vagy bármely más, az absztrakt áb- 
rázolást támogató nyelv hatékony használatával. 


A programozás eljárásközpontú és objektumorientált szemléletei alapvetően különböznek 
és ugyanarra a problémára jellemzően gyökeresen különböző megoldásokat adnak. Ez 
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a megfigyelés éppúgy igaz a tervezési, mint a megvalósítási szakaszra: lehet összpontosíta- 
ni az elvégzendő tevékenységekre és az ábrázolandó fogalmakra, de nem lehet egyszerre 
mindkettőre. 


Miért részesítjük előnyben az , objektumorientált tervezést" a funkcionális lebontáson ala- 
puló hagyományos tervezési módszerekkel szemben? Elsősorban azért, mert az utóbbi nem 
biztosít elegendő lehetőséget az absztrakt adatábrázolásra. Ebből pedig az következik, 
hogy az eredményül kapott terv 


kevésbé módosítható, 

eszközökkel kevésbé támogatható, 

kevésbé alkalmas párhuzamos fejlesztésre, 
kevésbé alkalmas párhuzamos végrehajtásra. 


pp... 


A probléma az, hogy a funkcionális lebontás következtében a lényeges adatok globálisak 
lesznek, mivel amikor egy rendszer függvényekből álló fa szerkezetű, bármely adat, mely- 
re két függvénynek van szüksége, mindkettő számára elérhető kell, hogy legyen. Ez azt 
eredményezi, hogy az , érdekes" adatok egyre feljebb vándorolnak a fán a gyökér felé (ne 
feledjük, a számítástechnikában a fák mindig a gyökértől lefelé növekednek), ahogy egyre 
több függvény akar hozzájuk férni. Pontosan ugyanez a folyamat figyelhető meg az egy- 
gyökerű osztályhierarchiákban, melyekben az , érdekes" adatok és függvények hajlamosak 
felfelé vándorolni egy gyökérosztály felé (424.4). A problémát úgy oldhatjuk meg, ha az 
osztályok meghatározására és az adatok , betokozására" (encapsulation) összpontosítunk, 
így ugyanis a programrészek közötti függéseket áttekinthetővé tehetjük, és — ami még fon- 
tosabb — csökkentjük a programban levő függőségek számát, azáltal, hogy az adatokra va- 
ló hivatkozások lokálisak lesznek. 


Egyes problémákat azonban a legjobban a megfelelő eljárások megírásával oldhatunk meg. 
Az objektumorientált megközelítésnél a tervezés lényege nem az, hogy egyetlen nem tag 
függvény se legyen a programban vagy hogy a rendszer egyetlen része se legyen eljárás- 
központú. Lényegesebb, hogy a program különböző részeit úgy válasszuk el, hogy jobban 
tükrözzék a fogalmakat. Ez általában úgy érhető el a legjobban, ha elsősorban az osztályok 
és nem a függvények állnak a tervezés középpontjában. Az eljárásközpontú stílus haszná- 
lata tudatos döntés kell, hogy legyen, nem pedig az , alapértelmezés". Az osztályokat és el- 
járásokat az alkalmazásnak megfelelően kell használni, nem egy rugalmatlan tervezési 
módszer , melléktermékeiként". 
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24.2.2. Az öröklés elkerülése 


Tegyük fel, hogy a tervezésnél nem építünk az öröklésre. Az eredményül kapott program 
nem fog élni a Cs egyik legelőnyösebb tulajdonságával, miközben persze kihasználja 
a Ct4 sok más előnyét a C, Pascal, Fortran, COBOL stb. nyelvekkel szemben. A leggyak- 
rabban hangoztatott érvek — a ,tehetetlenségtől" eltekintve — ,az öröklés használata csak 
részletkérdés a megvalósítás során", ,az öröklés megsérti az adatrejtés elvét" és ,az öröklés 
megnehezíti az együttműködést más programokkal". 


Az öröklést pusztán részletkérdésnek tekintve nem vesszük figyelembe azt, hogy az osz- 
tályhierarchiák közvetlenül ábrázolják az alkalmazási terület fogalmai közötti kapcsolato- 
kat. Márpedig az ilyen kapcsolatokat nyilvánvalóvá kell tenni a tervezésben, hogy a terve- 
zők vitatkozhassanak róluk. 


Előfordulhat az is, hogy az öröklést olyan C4- programrészekből zárjuk ki, amelyek köz- 
vetlenül érintkeznek más nyelveken írott kóddal. Ez azonban nem elégséges ok arra, hogy 
a program egészében elkerüljük az öröklést, csupán a program , külvilág" felé mutatott fe- 
lületét kell gondosan leírnunk és ,betokoznunk". Hasonlóképpen, az adatrejtésnek az 
öröklés általi veszélyeztetése miatti aggályok (424.3.2.1) csak arra adnak okot, hogy elővi- 
gyázatosak legyünk a virtuális függvények és védett tagok használatával (415.3), az öröklő- 
dés általános elkerülésére nem. 


Sok esetben nem származik valódi előny az öröklésből. A nagyobb programoknál azonban 


FTk 


a , nincs öröklés" megközelítés kevésbé áttekinthető és rugalmatlanabb rendszert eredmé- 
nyez. Az öröklést ekkor csak , tettetjük", hagyományos nyelvi szerkezetek és tervezési mó- 
dok használatával. Az is valószínű, hogy az ilyen hozzáállás ellenére az öröklést mégis hasz- 
nálni fogjuk, mert a C4t-4 programozók a program több részében is meggyőző érveket 
fognak találni az öröklés alapú tervezés mellett. Ezért a , nincs öröklés" csak azt fogja ered- 
ményezni, hogy a program felépítése nem lesz következetes és az osztályhierarchiák hasz- 


nálata csak egyes alrendszerekre fog korlátozódni. 


Más szóval, ne legyünk elfogultak. Az osztályhierarchiák nem minden jó program nélkülöz- 
hetetlen részei, de sok esetben segíteni tudnak mind az alkalmazás megértésében, mind 
egy megoldás kifejezésében. Az a tény, hogy az öröklést lehet helytelen vagy túlzott mó- 
don használni, ok az óvatosságra, de a tiltásra nem. 
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24.2.3. A statikus típusellenorzés figyelmen kívül hagyása 


Vegyünk azt az esetet, amikor a tervezésnél elhanyagoljuk a statikus típusellenőrzést. Ezt ál- 
talában a következőkkel indokolják: , a típusok a programozási nyelv termékei", , természe- 
tesebb objektumokban és nem típusokban gondolkodni" és , a statikus típusellenőrzés arra 
kényszerít, hogy túl korán gondoljunk a megvalósítás kérdéseire". Ez a hozzáállás addig jó, 
amíg nem okoz kárt. Tervezéskor ésszerűnek tűnhet nem foglalkozni a típusellenőrzés 
részleteivel, és az elemzési és a korai tervezési szakaszban általában nyugodtan figyelmen 
kívül is hagyhatjuk ezeket a kérdéseket. Az osztályok és osztályhierarchiák azonban na- 
gyon hasznosak a tervezésben. Nevezetesen megengedik, hogy a fogalmakat ábrázolhas- 
suk, kapcsolataikat meghatározhassuk, és segítenek, hogy a fogalmakról vitázzunk. A ter- 
vezés előrehaladtával ez a pontos ábrázolás az osztályokról és felületeikról tett egyre 
precízebb megállapítások formájában jelentkezik. 


Fontos, hogy észrevegyük, hogy a pontosan meghatározott és erősen típusos (lényegében 
típusokra építő) felületek a tervezés alapvető eszközei. A C4- felépítése is ennek figyelem- 
be vételével történt. Egy erősen típusos felület biztosítja (egy határig), hogy csak kompati- 
bilis programrészeket lehessen együtt fordítani és összeszerkeszteni, ami lehetővé teszi, 
hogy ezek a programrészek egymásról viszonylag erős feltételezésekkel élhessenek. Eze- 
ket a feltételezéseket a típusrendszer biztosítja; hatására csökkenteni lehet a futási idejű el- 
lenőrzést, ezáltal nő a hatékonyság és jelentősen rövidül a többszemélyes projektek 
integrálási szakasza. Valójában az erősen típusos felületekről gondoskodó rendszerek in- 
tegrálásában szerzett nagyon pozitív tapasztalatok okozzák, hogy az integrálás nem kap 
nagy teret e fejezetben. 


Nézzünk egy hasonlatot. Gyakran kapcsolunk össze különböző szerkentyűket, a csatla- 
kozó-szabványok száma pedig látszólag végtelen. A dugaszoknál kézenfekvő, hogy egye- 
di célra tervezettek, ami lehetetlenné teszi két szerkezet egymással való összekapcsolását, 
hacsak nem pont erre tervezték őket, ez esetben viszont csak a helyes módon kapcsolha- 
tók össze. Nem lehet egy villanyborotvát egy nagyfeszültségű aljzatba bedugni. Ha lehetne, 
az eredmény vagy egy , sült villanyborotva" vagy égési sérülés lenne. A tervezők igen talá- 
lékonynak bizonyultak, hogy biztosítsák, hogy az össze nem illő hardvereszközöket ne le- 
hessen egymással összedugni. A nem megfelelő dugaszok ellen lehet olyan készülékeket 
készíteni, melyek az aljzataikba dugott készülékek nemkívánatos viselkedésével szemben 
megvédik magukat. Jó példa erre egy elektromos zavarvédő. Miután a dugaszok szintjén 
nem garantálható a teljes összeegyeztethetőség, alkalmanként szükségünk van drágább vé- 
dőáramkörökre, melyek dinamikusan alkalmazkodnak a bemenethez vagy védelmet nyúj- 
tanak azzal szemben. 
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A hasonlat majdnem pontos. A statikus típusellenőrzés a dugasz megfelelőségének biztosí- 
tásával egyenértékű, a dinamikus ellenőrzés pedig az alkalmazkodó/védő áramkörnek fe- 
lel meg. Ha mindkét ellenőrzés hiányzik, az komoly kárt okozhat. Nagy rendszerekben 
mindkét ellenőrzési formát használják. A tervezés korai szakaszában ésszerű lehet egysze- 
rűen kijelenteni, hogy , ezt a két készüléket össze kell dugni", hamarosan fontos lesz azon- 
ban, hogy pontosan megmondjuk, hogyan kell összedugni őket. Milyen garanciákat ad 
a dugasz a viselkedéssel kapcsolatban? Milyen körülmények között fordulhatnak elő hibák? 


Milyen költségekkel jár a megfelelő viselkedés biztosítása? 


A statikus típusellenőrzés használata nem korlátozódik a , fizikai világra". A mértékegysé- 
gek (pl. méter, kilogramm, másodperc) használata a fizikában és a mérnöki tudományok- 
ban az össze nem egyeztethető elemek összekeverését akadályozza meg. 


Amikor a 423.4.3-ban a tervezés lépéseit ismertettük, a típusinformációk a 2. lépésben ke- 
rültek elő (az 1. lépésben rendszerint csak felületesen foglalkozunk velük), és a 4. lépésben 
váltak központi kérdéssé. 


A statikusan ellenőrzött felületek a különböző programozói csoportok által fejlesztett C-H- 
programok együttműködésének fő biztosítékai. Ezek dokumentációja (beleértve a használt 
típusokét is) az elsődleges kapcsolattartási eszköz az egyes programozói csoportok között. 
Ezen felületek jelentik a tervezési folyamat legfontosabb eredményét és ezek állnak a ter- 
vezők és programozók közötti kapcsolat középpontjában. 


A típusok elhanyagolása a felületek kialakításánál olyan felépítéshez vezet, amely homály- 
ba burkolja a program szerkezetét és a futás idejéig elhalasztja a hibák észlelését. Tegyük 
fel például, hogy egy felületet önazonosító objektumokkal írunk le: 


// a példa dinamikus típusellenőrzést feltételez statikus ellenőrzés helyett 
Stack s; // a verem bármilyen típusú objektumra hivatkozó mutatókat tárolhat 


void fJO 

( 
s.push(new Saab900)9; // ez egy autótípus 
s.push(new Saab37B); // ez egy repülőtípus 


s. popO-:takeoffO; // jó: a Saab 37B egy repülőgép 
s. bpopO-:takeoffO; // futási idejű hiba: egy autó nem tud felszállni 
j 
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Ez a felület (a Stack::bushO felületének) komoly túlegyszerűsítése, ami statikus ellenőrzés 
helyett dinamikus ellenőrzésre épít. Az s verem , repülőgépek" (Plane) tárolására való, de 
ez a kódban rejtett maradt, így a felhasználó kötelessége lesz e követelmény betartását biz- 
tosítani. 


Egy precízebb meghatározás — egy sablon és egy virtuális függvény a megszorítás nélküli dinamikus tí- 
pusellenőrzés helyett — a hibák észlelését a futási időből átteszi a fordítási időbe: 


StackcPlane" 5 s; // a verem Plane-ekre hivatkozó mutatókat tárolhat 
void JO 
( 

s. push(new Saab900); // hiba: a Saab900 nem Plane típusú 

s.push(new Saab37B); 

s.popO-:takeoffO; // rendben: a Saab 37B egy repülőgép 


s.popO--takeoffO; 


j 


Hasonló kérdést tárgyal a §16.2.2 pont. A különbség a futási idejű dinamikus ellenőrzés és 
a statikus ellenőrzés között jelentős lehet. A dinamikus ellenőrzés rendszerint 3-10-szer 
több feladatot ró a rendszerre. Nem szabad viszont a másik végletbe sem esni. Nem lehet 
statikus ellenőrzéssel minden hibát elcsípni. Még a legalaposabb statikusan ellenőrzött 
program is ki van téve a hardverhibák okozta sérülésnek. A §25.4.1 pontban további példát 
találhatunk arra, hogy nem lehet tökéletes statikus ellenőrzést megvalósítani, az ideális 
azonban az, ha a felületek nagy többsége alkalmazásszintű statikus típusokat használ (lásd 
§24.4.2). 


Egy másik probléma, hogy a terv elvont szinten lehet tökéletesen ésszerű, de komoly prob- 
lémákat okozhat, ha nem számol a használt eszköz (esetünkben a C-t-) korlátaival. Példá- 
ul, egy JÖ függvény, mely egy paraméterén a turn right műveletet hajtja végre, csak ak- 
kor hozható létre, ha minden paramétere ugyanolyan típusú: 


class Plane f 
Ses 
void turn rightO; 


J; 


class Car f 
Mséő 
void turn rightO; 


J; 
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void MX" p) // milyen típus kell legyen X? 


í 
b-eturn rightO; 
24 ssel 

) 


Egyes nyelvek (mint a Smalltalk és a CLOS) megengedik két ugyanazon műveletekkel ren- 
delkező típus felcserélt használatát, azáltal, hogy minden típust egy közös bázisosztály ál- 
tal kapcsolnak össze és a futási időre halasztják a név feloldását. A Ct-4 azonban ezt (szán- 
dékosan) csak sablonokkal (template) és fordítási idejű feloldással támogatja. Egy nem 
sablon függvény két különböző típusú paramétert csak akkor fogad el, ha a két típus auto- 
matikusan közös típusra konvertálható. Az előbbi példában tehát az X-nek a Plane és Car 
(Autó) közös bázisosztályának kell lennie (pl. a Vehicle (Jármű) osztálynak). 


A C4--tól idegen fogalmakra épülő rendszerek természetesen ábrázolhatók a C-t--ban is, 
ha a kapcsolatokra vonatkozó feltételezéseket kifejezetten megadjuk. A Plane és a Car pél- 
dául (közös bázisosztály nélkül is) osztályhierarchiába helyezhető, ami lehetővé teszi, hogy 
átadjunk egy Car-t vagy Plane-t tartalmazó objektumot f(X"J-nek (425.4.1). Ha azonban ezt 
tesszük, az gyakran nemkívánatos mennyiségű műveletet és ügyességet követel, de a sab- 


lonok hasznos eszköznek bizonyulhatnak az ilyen leképezések egyszerűsítésére. A terve- 
zési fogalmak és a Ct-4 közti rossz megfeleltetés általában , természetellenes kinézetű" és 
kis hatékonyságú kódhoz vezet. A ,karbantartó" programozók nem szeretik a nyelvben 


szokatlan kódot, amely ilyen rossz megfeleltetésekből származik. 


A tervezési mód és a megvalósításhoz használt nyelv közti rossz megfeleltetés hasonlít 
a (természetes nyelvek esetében végzett) , szóról szóra" fordításhoz. Például az angol nyelv 
magyar nyelvtannal ugyanolyan nehézkes, mint a magyar nyelv angol nyelvtannal, annak 
pedig, aki csak a két nyelv egyikét beszéli folyékonyan, mindkét változat érthetetlen lehet. 


A programban lévő osztályok a tervezés fogalmainak konkrét ábrázolásai. Következéskép- 
pen, ha az osztályok közötti kapcsolatok nem világosak, a terv alapfogalmai sem lesznek 
azok. 


24.2.4. A programozás elkerülése 


A programozás sok más tevékenységhez képest költséges és előre nehezen felmérhető 
munka, az eredményül kapott kód pedig gyakran nem 10096-ig megbízható. A programo- 
zás munkaigényes és — számos okból -— a munkát általában az hátráltatja a legkomolyabban, 
ha egy kódrész nem átadásra kész. Nos, miért ne küszöböljük ki a programozást, mint te- 
vékenységet, egészében véve? 
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Sok vezető számára jelentős előnnyel járna megszabadulni az arrogáns, túlfizetett, szak- 
mailag megszállott, nem megfelelő öltözékű stb. programozóktól?. Egy programozónak 
persze ez a javaslat abszurdnak hangzik. Vannak azonban olyan fontos területek, melyeknél 
a programozásnak vannak valós alternatívái. Egyes esetekben lehet közvetlenül egy magas 
szintű ábrázolásból létrehozni a kódot; másutt a képernyőn lévő alakzatok kezelésével. Köz- 
vetlen kezeléssel használható felhasználói felületeket lehet építeni annak az időnek tört ré- 
sze alatt, ami ugyanezen felületnek hagyományos kóddal való leírásához kellene. Ugyanígy 
kódot készíthetünk adatbázis-kapcsolatokhoz és az adatok ilyen kapcsolatok szerinti hozzá- 
féréséhez pusztán azokból a specifikációkból, melyek sokkal egyszerűbbek, mint a művele- 
tek közvetlen kifejezéséhez szükséges — C4--ban vagy más, általános célú programozási 
nyelven - írt kód. Ilyen leírásokból/meghatározásokból vagy egy közvetlen kezelőfelület se- 
gítségével állapotautomaták (state machines) készíthetők, melyek kisebbek, gyorsabbak és 
jobban működnek, mint amit a legtöbb programozó képes volna alkotni. 


Ezek a módszerek olyan területeken használhatók jól, ahol erősek az elméleti alapok (pl. 
matematika, állapotautomaták, relációs adatbázisok) vagy van egy általános váz, amelybe 
be lehet ágyazni kis programtöredékeket (pl. grafikus felhasználói felületek, 
hálózatszimulációk, adatbázis-sémák). Az a tény, hogy ezen módszerek egyes lényeges te- 
rületeken (bár ezek köre korlátozotD) igen hasznosak lehetnek, elhitethetik velünk, hogy 
a hagyományos programozás kiváltása e módszerek segítségével ,már a küszöbön áll". 
Nem így van: ha az ábrázolási módszerek az erős elméleti vázon túllépnek, a leíró nyelv 
szükségszerűen éppoly bonyolult lesz, mint egy általános célú programozási nyelv. 


Néha elfelejtjük, hogy a váz, mely valamely területen lehetőséget ad a hagyományos prog- 
ramozás kiküszöbölésére, valójában egy hagyományos módon tervezett, programozott és 
tesztelt rendszer vagy könyvtár. A C4- és az e könyvben leírt eljárások egyik népszerű fel- 
használása is pontosan ilyen rendszerek tervezése és építése. 


A legrosszabb eset, ha egy általános célú nyelv kifejező képességének csak a töredékét biz- 
tosító kompromisszumos megoldást az eredeti (korlátozott) alkalmazási területen kívül kell 
felhasználnunk. A tervezők, akik egy magas szintű modellezési szemponthoz ragaszkod- 
nak, bosszankodnak a bonyolultság miatt és olyan rendszerleírást készítenek, melyből ször- 
nyűséges kód jön létre, a közönséges programozási eljárásokat használó programozók pe- 
dig csalódottak lesznek a nyelvi támogatás hiánya miatt, és jobb kódot csak túlzott 
erőfeszítéssel és a magasszintű modellek elhagyásával lesznek képesek készíteni. 


Nem látom jelét annak, hogy a programozás, mint tevékenység sikeresen kiküszöbölhető 
lenne az olyan területeken kívül, amelyeknek jól megalapozott elmélete van vagy amelyek- 
ben az alapvető programozási módszer egy vázhoz igazodik. A hatékonyság mindkét eset- 
ben drámai módon lecsökken, amint elhagyjuk az eredeti vázat és általánosabb célú mun- 





4 Igen. Én programozó vagyok. 
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kát kísérelünk meg elvégezni. Mást színlelni csábító, de veszélyes dolog. Ugyanakkor őrült- 
ség lenne figyelmen kívül hagyni a magas szintű leírásokat és a közvetlen kezelésre szolgá- 
ló eljárásokat olyan területeken, ahol azok jól megalapozottak és meglehetősen kiforrottak. 


Az eszközök, könyvtárak és vázak tervezése a tervezés és programozás egyik legmagasabb 
rendű fajtája. Jól használható matematikai alapú modellt építeni egy alkalmazási területre 
az egyik legmagasabb rendű elemzésfajta. Adni egy eszközt, nyelvet, vázat stb., amely az 
ilyen munka eredményét ezrek számára teszi elérhetővé, módot ad a programozóknak és 
a tervezőknek elkerülni a csapdát, hogy tucattermékek készítőivé váljanak. 


A legfontosabb, hogy az adott leíró rendszer vagy alapkönyvtár képes legyen felületként 
hatásosan együttműködni egy általános célú programozási nyelvvel. Egyébként az adott 
váz magában hordja korlátait. Ebből következik, hogy azon leíró vagy közvetlen kezelést 
biztosító rendszereknek, melyek megfelelően magas szintű kódot készítenek valamilyen el- 
fogadott általános célú programozási nyelven, nagy előnyük van. Az egyedi nyelvek hosszú 
távon csak készítőiknek jelentenek könnyebbséget. Ha a létrehozott kód olyan alacsony 
szintű, hogy a hozzátett általános kódot az absztrakt ábrázolás előnyei nélkül kell megírni, 
elveszítjük a megbízhatóságot, a módosíthatóságot és a gazdaságosságot. Egy kódkészítő 
rendszert lényegében úgy kell megírni, hogy egyesítjük a magasabb szintű leírások és a ma- 
gasabb szintű nyelvek erősségeit. Kihagyni az egyiket vagy a másikat annyi, mint feláldoz- 
ni a rendszerépítők érdekeit az eszközkészítők érdekeiért. A sikeres nagy rendszerek több- 
szintűek, modulárisak és folytonosan fejlődnek. Következésképpen az ilyen rendszerek 
megalkotását célzó sikeres erőfeszítésekbe sokféle nyelvet, könyvtárat, eszközt és módszert 
kell bevonni. 


24.2.5. Az osztályhierarchiák kizárólagos használata 


Amikor úgy találjuk, hogy egy újdonság tényleg működik, gyakran esünk túlzásba, és nyak- 
ra-főre azt alkalmazzuk. Más szóval, az egyes problémák esetében jó megoldásról gyakran 
hisszük, hogy gyógyírt jelenthet majdnem minden problémára. Az osztályhierarchiák és az 
objektumokon végzett többalakú (polimorf) műveletek sok problémára adnak jó megol- 
dást, de nem minden fogalom ábrázolható a legjobban egy hierarchia részeként, és nem 
minden programkomponens legjobb ábrázolása egy osztályhierarchia. 


Miért nem? Az osztályhierarchia kapcsolatokat fejez ki osztályai között, az osztály pedig egy 
fogalmat képvisel. Nos, akkor mi a közös kapcsolat egy mosoly, a CD-meghajtóm, Richard 
Strauss Don Juanjának egy felvétele, egy sor szöveg, egy műhold, az orvosi leleteim és egy 
valósidejű óra között? Ha az egészet egyetlen hierarchiába helyezzük, miközben egyetlen 
közös tulajdonságuk, hogy mindnyájan programozási elemek (, objektumok"), csak kevés 
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értékkel bíró, zavaros rendszert hozunk létre (415.4.59. Ha mindent egyetlen hierarchiába 
erőltetünk, mesterséges hasonlóságok jöhetnek létre és elhomályosíthatják a valódi egye- 
zéseket. Hierarchiát csak akkor szabad használnunk, ha az elemzés fogalmi közösséget mu- 
tat ki, vagy ha a tervezés és programozás fed fel egyezéseket a fogalmak ábrázolására hasz- 
nált szerkezetekben. Az utóbbi esetben nagyon figyelnünk kell arra, hogy 
megkülönböztessük a valódi (altípusok által örökölt nyilvános tulajdonságban tükröződő) 
közösséget és a hasznos egyszetűsítéseket (ami privát öröklésben tükröződik, 424.3.2.1. 


Ez a gondolatmenet olyan programhoz vezet, melyben számos egymással kapcsolatban 
nem lévő, vagy gyengén kapcsolódó osztályhierarchia van, és ezek mindegyike szorosan 
összekapcsolt fogalmak halmazát képviseli. Elvezet a konkrét osztály (425.2) fogalmához is, 
mely nem hierarchia tagja, mert egy ilyen osztályt hierarchiába helyezve csorbítanánk az 
osztály teljesítőképességét és függetlenségét a rendszer többi részétől. A hatékonyság 
szemszögéből egy osztályhierarchia részét képező osztály leglényegesebb műveleteinek 
virtuális függvényeit kell tekintenünk, továbbá az osztály számos adatának privát (private) 
helyett védettnek (protected) kell lennie. Ez persze sebezhetővé teszi a további származta- 
tott osztályok módosításaival szemben és komoly bonyodalmakat okozhat a tesztelésnél. 
Ott, ahol tervezési szempontból szigorúbb betokozást (enkapszuláció) érdemes használni, 


nem virtuális függvényeket és privát adatokat kell alkalmazni (424.3.2.1. 


Ha egy műveletnek egyetlen paramétere van (az, amelyik , az objektumot" jelöli), a terv ál- 
talában torzul. Ha több paraméterrel egyformán lehet bánni, a művelet egy nem tag függ- 
vénnyel ábrázolható a legjobban. Ebből nem következik, hogy az ilyen függvényeket glo- 
bálissá kell tennünk, csupán az, hogy majdnem minden ilyen önálló függvénynek egy 
névtér tagjának kell lennie (424.4). 


24.3. Osztályok 


Az objektumorientált tervezés és programozás alapvető elve, hogy a program a valóság va- 
lamely részének modellje. A programban az osztályok a modellezett , valóság" alapfogalma- 
it, míg ezen osztályok objektumai a valós világbeli objektumokat és a megvalósítás során 
létrehozott elemeket ábrázolják. 


Az osztályok közti és egy osztály részein belüli kapcsolatok elemzése a rendszer tervezésé- 
ben központi szerepet játszik: 
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§24.3.2  Öröklési kapcsolatok 

§24.3.3 — Tartalmazási kapcsolatok 
§24.3.5 — Használati kapcsolatok 
424.2.4 Beprogramozott kapcsolatok 
§24.3.7 — Osztályon belüli kapcsolatok 


Mivel a Csi osztályai típusok, az osztályok és az osztályok közötti kapcsolatok jelentős tá- 
mogatást kapnak a fordítóprogram részéről és általában a statikus elemzés alá tartoznak. 


Ahhoz, hogy a rendszerben fontos legyen, egy osztálynak nemcsak használható fogalmat 
kell ábrázolnia; megfelelő felületet is kell nyújtania. Az ideális osztály alapvetően csekély 
mértékben, de pontosan meghatározottan függ a többi programelemtől, és olyan felületet 
nyújt, amely azok számára csak a feltétlenül szükséges információkat biztosítja (§24.4.2). 


24.3.1. Mit ábrázolnak az osztályok? 
Egy rendszerben lényegében kétfajta osztály van: 


1. Osztályok, melyek közvetlenül az alkalmazási terület fogalmait ábrázolják; azaz 
olyan fogalmakat, melyeket a végfelhasználók használnak a problémák és meg- 
oldások ábrázolására. 

2. Osztályok, melyek a megvalósításból következnek, vagyis olyan fogalmak, melye- 
ket a tervezők és programozók a megvalósítási módszerek leírására használnak. 


Néhány osztály, mely a megvalósítás , terméke", ábrázolhat valóságos dolgot is. A rendszer 
hardver- és szoftver-erőforrásai például alkalmasak arra, hogy egy programban osztályok 
legyenek. (Ez azt a tényt tükrözi, hogy egy rendszer több nézőpontból is tekinthető.) Ebből 
következik, hogy ami valaki számára csak a megvalósítás részletkérdése, az más számára 
a teljes alkalmazás lehet. Egy jól tervezett rendszer olyan osztályokat tartalmaz, melyek 
a rendszer logikailag önálló nézeteit ábrázolják: 


Felhasználói szintű fogalmakat ábrázoló osztályok (pl. autók és teherautók) 
Felhasználói fogalmak általánosításait ábrázoló osztályok (pl. járművek) 
Hardver-erőforrásokat ábrázoló osztályok (pl. egy memóriakezelő osztály) 
Rendszer-erőforrásokat ábrázoló osztályok (pl. kimeneti adatfolyamok) 

Más osztályok megvalósítása használt osztályok (pl. listák, várakozási sorok, zárak) 
Beépített adattípusok és vezérlési szerkezetek 
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Nagyobb rendszerekben kihívást jelent a logikailag önálló osztálytípusok elválasztása és 
a különböző elvonatkoztatási (fogalmi) szintek közötti elkülönítés fenntartása. Vegyünk 
egy egyszerű példát, ahol három fogalmi szintünk van: 


1-2 A rendszer alkalmazásszintű nézete 
344 Annak a gépnek az ábrázolása, amelyen a , modell" fut 
546 A megvalósítás alacsonyszintű (programozási nyelvi) nézete 


Minél nagyobb a rendszer, annál több fogalmi szintre van szükség annak leírásához és annál 
nehezebb a szinteket meghatározni és fenntartani. Vegyük észre, hogy az ilyen fogalmi szin- 
teknek közvetlen megfelelői vannak mind a természetben, mind a más típusú, ember által 
létrehozott rendszerekben. Egy ház például úgy is tekinthető, mint ami az alábbiakból áll: 


atomok, 

molekulák, 

faanyag és tégla, 

padló, falak és mennyezet, 
szobák. 


SJ ars STO E 


Mindaddig, amíg ezek a szintek külön maradnak, fenntartható a ház fogalmának követke- 
zetes megközelítése, ha azonban keverjük őket, abszurditások keletkeznek. Például az a ki- 
jelentés, hogy , Az én házam többezer kiló szénből, komplex polimerből, kb. 5000 téglából, 
két fürdőszobából és 13 mennyezetből áll", ostobaság. A programok absztrakt természeté- 
ből adódik, hogy ha egy bonyolult programrendszerről hasonló kijelentést teszünk, azt nem 
mindig lehet ilyen egyszerűen minősíteni. 


Az alkalmazási terület valamely fogalmának , lefordítása" egy tervezési osztályra nem egy- 
szerű, mechanikus művelet, gyakran jelentős áttekintést követel. Vegyük észre, hogy magu- 
kat az adott alkalmazási terület fogalmait is elvonatkoztatás segítségével írjuk le. Például 
, adófizetők", , szerzetesek" és , alkalmazottak" a természetben nem léteznek; az ilyen fogal- 
mak csupán címkék, melyeket egyénekre aggatunk, hogy valamely rendszer szerint osztá- 
lyozzuk őket. A valós, sőt a képzelt világból (az irodalomból, különösen a tudományos fan- 
tasztikumbóbl merített fogalmak gyökeresen megváltoznak, amikor osztályokkal ábrázoljuk 
azokat. A PC képernyője például nem igazán emlékeztet az íróasztalra, sokszor mégis ezzel 
a hasonlattal írják le?, a képernyőn lévő ablakok pedig csak halványan emlékeztetnek 
azokra a szerkezetekre, melyek huzatot engednek be az irodába. A valóság modellezésénél 
nem az a lényeg, hogy szolgai módon kövessük azt, amit látunk, hanem hogy a tervezés ki- 
induló pontjaként, ösztönző forrásként, és horgonyként használjuk azt, melybe kapaszkod- 
hatunk, amikor a program megfoghatatlan természete azzal fenyeget, hogy legyőzi azt a ké- 
pességünket, hogy megértsük saját programjainkat. 





5 Én semmiképpen sem tűrnék akkora rendetlenséget a képernyőmön. 
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Egy figyelmeztetés: a kezdők gyakran nehezen , találják meg az osztályokat", de ezt a prob- 
lémát rendszerint hamarosan leküzdik, , maradandó" káros hatások nélkül. Ezt azonban 
gyakran követi egy szakasz, amelyben az osztályok - és azok öröklési kapcsolatai — látszó- 
lag ellenőrizhetetlenül megsokszorozódnak, ami hosszú távon viszont bonyolultabbá és át- 
tekinthetetlenebbé teheti az eredményül kapott programot és ronthatja annak hatékonysá- 
gát. Nem kell minden kis részletet külön osztállyal és minden osztályok közötti kapcsolatot 
öröklési kapcsolattal ábrázolni. Próbáljuk észben tartani, hogy a tervezés célja a rendszer 
megfelelő részletességgel és megfelelő elvonatkoztatási szinten való modellezése. Az egy- 
szerűség és az általánosság között nem könnyű az egyensúlyt megtalálni. 


24.3.2. Osztályhierarchiák 


Vegyük egy város forgalmának szimulációját: meg kell határoznunk, várhatóan mennyi idő- 
re van szükség, hogy a mentőjárművek rendeltetési helyükre érjenek. Világos, hogy ábrá- 
zolnunk kell autókat, teherautókat, mentőautókat, különféle tűzoltójárműveket, rendőrau- 
tókat, buszokat és így tovább. Az öröklés mindenképpen szerephez jut, mivel a valós 
világbeli fogalmak nem léteznek elszigetelten, csak más fogalmakkal kapcsolatban. A kap- 
csolatok megértése nélkül nem érthetjük meg a fogalmakat sem. Következésképpen az 
a modell, amely nem ábrázol ilyen kapcsolatokat, nem ábrázolja megfelelően a fogalmakat 
sem. Programjainkban tehát szükségünk van osztályokra a fogalmak ábrázolásához, de ez 
nem elég; szükségünk van az osztályok kapcsolatainak ábrázolására is. Az öröklés kitűnő 


módszer hierarchikus kapcsolatok közvetlen ábrázolására. Példánkban a mentőjárműveket 


e) 


valószínűleg különlegesnek tekintenénk és megkülönböztetnénk , autószerű" és , teherau- 


vé) 


tószerű" járműveket is. Az osztályhierarchia ezek alapján így nézne ki: 


Vehicle 





Emergency Truck 





Police car Ambulance Fire engine 


Hook and ladder 
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Itt az Emergency a megkülönböztetett járművek azon jellemzőit képviseli, melyek a szimu- 
láció szempontjából lényegesek: megsérthet bizonyos forgalmi szabályokat, elsőbbsége 
van az útkereszteződésekben, diszpécser irányítja stb. 


Íme a Cst változat: 


class Vehicle f/£ ..."/); // Jármű 

class Emergency ( / ..."/ 2; // Megkülönböztetett 
class Car : public Vehiclef / ...?/ 2; // Autó 

class Truck : public Vehicle f/£ ..."/ ); // Teherautó 

class Police car : public Car , protected Emergency f / ...§/9); —— // Rendőrautó 

class Ambulance : public Car , protected Emergency f / ...?/ ); // Mentőautó 
class Fire engine : public Truck , protected Emergency f / ..."/ ); // Tűzoltóautó 
class Hook and laddaer : public Fire enginef / ...?/); // Létrásautó 


Az öröklés a Cs--ban közvetlenül ábrázolható legmagasabb szintű kapcsolat, és a tervezés 
korai szakaszában a legnagyobb a szerepe. Gyakran választhatunk, hogy öröklést vagy tag- 
ságot használunk-e egy kapcsolat ábrázolására. Nézzünk egy másik megközelítést, mit is je- 
lent megkülönböztetett járműnek lenni: egy jármű megkülönböztetett, ha villogó fényjelző- 


je van. Ez lehetővé tenné, hogy úgy egyszerűsítsük az osztályhierarchiát, hogy az 
Emergency osztályt a Vehicle osztály egyik tagjával helyettesítjük: 


Vehicle f eptr ) 


zzz CE 





Car Truck 
Police car Ambulance Fire engine 


Hook and ladder 


Az Emergency osztályt most egyszerűen azon osztályok tagjaként használjuk, melyeknek 
szükségük lehet arra, hogy megkülönböztetett járműként szerepeljenek: 
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class Emergency € /£ ...§/ 3; 

class Vehicle f protected: Emergency"? eptr; /£ ..."/); // jobb: helyes hozzáférést biztosít eptr- 
hez 

class Car : public Vehicle €/£ ...§/); 

class Truck : public Vehicle €/£ ..."/); 

class Police car : public Carf / ...t/); 

class Ambulance : public Car € /£ ...§/); 

class Fire engine : public Truck €/f ...§/); 

class Hook and ladder : public Fire engine ( /? ..."/ ); 


Itt egy jármű akkor megkülönböztetett, ha a Vehicle::eptr nem nulla. A , sima" autóknál és 


teherautóknál a Vehicle::eptr kezdőértéke nulla; a többinél nem nulla: 


Car::CarO // Car konstruktor 
í 
eptr — 0; 
) 
Police car::Police carO // Police car konstruktor 
( 
eptr - new Emergency; 
; 


Az elemek ilyen meghatározása lehetővé teszi, hogy egy megkülönböztetett járművet kö- 
zönséges járművé alakítsunk át és megfordítva: 


void KVehicle? p) 
( 
delete b-2eptr; 
b-2eptr — 0; // Többé nem megkülönböztetett jármű 
Mea 
b-2eptr - new Emergency; // Ismét megkülönböztetett jármű 
J 


Nos, melyik jobb osztályhierarchia? Az általános válasz: , Az a program, amely a valós világ 
bennünket legjobban érdeklő részét a legközvetlenebb módon modellezi." Vagyis a model- 
lek közti választáskor a cél a valóság minél jobb megközelítése, persze a hatékonyságra és 
egyszerűségre való törekvés mellett. Esetünkben a könnyű , átváltozás" a közönséges és 
megkülönböztetett járművek között számomra nem tűnik valószerűnek. A tűzoltóautók és 
a mentőautók különleges célra készült járművek, kiképzett személyzettel; eligazításuk pe- 
dig egyedi kommunikációs berendezéseket igényel. Ez a szemlélet jelzi, hogy megkülön- 


994 lervezés a C-t segítségével 


böztetett járműnek lenni alapvető fogalom és a programban közvetlenül kell ábrázolni, 
hogy segítse a típusellenőrzést és más eszközök használatát. Ha olyan helyet modellez- 
nénk, ahol a járművek szerepe kevésbé szigorúan meghatározott — mondjuk egy olyan te- 
rületet, ahol magánjárműveket szokás a mentőszemélyzet helyszínre szállítására használni 
és ahol a kommunikáció elsősorban hordozható rádiókon keresztül folyik, más modellezé- 
si módszer megfelelőbb lenne. Azok számára, akik a forgalomszimulációt elvontnak tekin- 
tik, érdemes lehet rámutatni, hogy az öröklődés és a tagság közti választás szinte minden 
esetben elkerülhetetlen (lásd a §24.3.3 gördítősáv példáján. 


24.3.2.1. Osztályhierarchián belüli függések 


A származtatott osztályok természetesen függnek bázisosztályaiktól. Ritkábban esik szó ró- 
la, de az ellenkezője is igaz lehet?ő. Ha egy osztálynak van virtuális függvénye, az osztály 
függ a belőle származtatott osztályoktól, melyek e függvény felülbírálásával az osztály 
egyes szolgáltatásait biztosítják. Ha magának a bázisosztálynak egy tagja hívja meg az osz- 
tály egyik virtuális függvényét, megint csak a bázisosztály függ a származtatott osztályaitól, 
saját megvalósítása miatt. Vegyük az alábbi példát: 


class Bf 
Isa 
brotected: 
int a; 
bublic: 
virtual int fO; 
int 90 f int x - fO; return x-a; ) 


J; 


Mit csinál g0 ? A választ jelentősen befolyásolja, definiálja /0-et valamelyik származtatott 
osztály. Íme egy változat, mely biztosítja, hogy g0 visszatérési értéke 17 lesz: 


class D1 : public Bf 
int JO ( return az 1; ) 


J; 


Íme egy másik, amely kiírja a , Helló, világ!" szöveget és nullával tér vissza: 


class D2 : public Bf 
int JO ( coutszs"Helló, világ Nm"; return a; ) 


J; 





6 Eza megfigyelés így összegezhető: , Az esztelenség örökölhető. A gyerekeidtől kapod meg." 
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A fentiek a virtuális függvényekkel kapcsolatos egyik legfontosabb dolgot szemléltetik. Mi- 
ért rossz a példa? Miért nem írna programozó soha ilyet? Azért, mert a virtuális függvények 
a bázisosztály felületének részei, és az osztály feltehetően a belőle származó osztályok is- 
merete nélkül is használható. Következésképpen úgy kell tudnunk meghatározni a 
bázisosztály egy objektumának elvárt viselkedését, hogy a származtatott osztályok ismere- 
te nélkül is írnassunk programokat. Minden osztály, mely felülírja (override) a virtuális függ- 
vényt, e viselkedésnek egy változatát kell, hogy leírja. Például a Shape (Alak) osztály 
rotate0 (forgatás) virtuális függvénye egy alakzatot forgat el. A származtatott Circle (Kör) 
és Triangle (Háromszög) osztályok rotate0 függvényeinek a nekik megfelelő típusú objek- 
tumokat kell forgatniuk, különben megsértenének egy alapvető feltételezést a Snape osz- 
tályról. A fenti B osztályról és a belőle származó DJ és D2 osztályokról ilyesmit nem téte- 
leztünk fel, ezért a példa értelmetlen. Még a B, D1, D2, fés g neveket is úgy választottuk 
meg, hogy bármilyen lehetséges jelentést homályban hagyjanak. A virtuális függvények el- 
várt viselkedésének meghatározása az osztályok tervezésének egyik fő szempontja. Jó ne- 
veket választani az osztályok és függvények számára szintén fontos — de nem mindig 
könnyű. 


Jó vagy rossz-e egy függés az ismeretlen (esetleg még meg sem írt) származtatott osztályok- 
tól? Természetesen ez függ a programozó szándékától. Ha egy osztályt úgy akar elszigetel- 
ni minden külső befolyástól, hogy az meghatározott módon viselkedjen, akkor legjobb el- 
kerülni a védett (protected) tagokat és a virtuális függvényeket. Ha azonban egy vázat akar 
adni, amelyhez egy későbbi programozó (vagy saját maga néhány héttel később) kódot ad- 
hat hozzá, a virtuális függvények használata ehhez elegáns módszert jelenthet, a protected 
tagfüggvények pedig jól támogatják az ilyen megoldásokat. Ezt a megoldást választottuk az 
adatfolyam [/O könyvtárban (§21.6), az Ival box hierarchia végső változatánál (§12.4.2) pe- 
dig példát is mutattunk rá. 


Ha egy virtuális függvényt csak a származtatott osztályok általi közvetett használatra szá- 
nunk, private maradhat. Példaként vegyük egy átmeneti tár (puffer) egyszerű sablonját: 


templatexclass T: class Buffer ( 


bublic: 
void put D; // overflow( IT) meghívása, ha az átmeneti tár megtelt 
T getO; // underflowO meghívása, ha a tár üres 
V/AKENS 

brivate: 


virtual int overflowC DD; 
virtual int underflowO; 
VAS 

zi 
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A putO és getŐ függvények a virtuális overflowO) illetve underflowO függvényeket hívják 
meg. A felhasználó ezen függvények felülírásával a különböző igények szerint egy sor tár- 
típust határozhat meg: 


templatexcilass T- class Circular. buffer : public BufferST- ( 
int overflow(1); . // körbelép, ha teli 
int underflowO; 
VS 


J; 
templatexclass T- class Expanding buffer : public BuffersT: ( 
int overflow(CI); . // megnöveli az átmeneti tárat, ha megtelt 
int underflowO; 


Ja 


J; 


Az overflowO és underflowO függvényeknek csak akkor kellene private helyett protected- 
nek lenniük, ha a származtatott osztálynak szüksége lenne e függvények közvetlen meg- 
hívására. 


24.3.3. Tartalmazási kapcsolatok 


Ott, ahol tartalmazást használunk, egy X osztály egy objektumát két fő módszerrel ábrázol- 
hatjuk: 


1.  Bevezetünk egy X típusú tagot. 
2.  Bevezetünk egy X" típusú vagy egy X£ típusú tagot. 


Ha a mutató értéke sohasem változik, ezek a megoldások egyenértékűek, kivéve a haté- 
konyság kérdéseit és azt a módot, ahogyan konstruktorokat és destruktorokat írunk: 


class X ( 

bublic: 
XGND; 
Mega 


ba 

class Cf 
X a; 
XX p; 
X£ Tr; 

bublic: 
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C(int i, int j, int k) : a(i), p(new X(j)), rö new X(R)) ( ) 
-C0 1 delete p; delete £r; ? 
3; 


Ilyen esetekben rendszerint előnyben kell részesítenünk magának az objektumnak a tagsá- 
gát (C::a), mert ez biztosítja a leggyorsabb működést, ez igényli a legkevesebb helyet, és 
persze ezt lehet a leggyorsabban leírni. Kevesebb hiba forrása is, mivel a tartalmazó és a tar- 
talmazott objektum kapcsolata a létrehozás és megsemmisítés szabálya alá tartozik (§10.4.1, 
§12.2.2, §14.4.1, de lásd még: §24.4.2 és §25.79. 

A mutatót használó megoldást akkor használjuk, ha a , tartalmazó" objektum élettartama 
alatt a , tartalmazott" objektumra hivatkozó mutatót meg kell változtatnunk: 


class C2 ( 
xX p; 

bublic: 
CXCint i) : p(new X(1) ( ) 
-C20 f delete p; ) 


Xt change(xt a 


S 
t 


bead DB; 
b7-d 
return t; 


) 
7 


Egy másik ok a mutató tag használatára, hogy meg akarjuk engedni a , tartalmazott" objek- 
tum paraméterként való szereplését: 


class C3 ( 
xX p; 

bublic: 
C3(Xt 9) : P( ( 
Ide 

sz 


Azáltal, hogy olyan objektumaink vannak, melyek más objektumokra hivatkozó mutatókat 
tartalmaznak, tulajdonképpen egy objektumhierarchiát hoztunk létre. Ez az osztályhierar- 
chiák használatát egyszerre helyettesítheti és kiegészítheti. Mint a §424.3.2 , jármű" példája 
mutatta, gyakran nehéz tervezéskor választani, hogy egy osztálytulajdonságot bázisosztály- 
ként vagy tagként ábrázoljunk. Ha felülírt függvényeket kell használnunk, az azt jelzi, hogy 
az első a jobb választás, ha pedig arra van szükség, hogy egy tulajdonságot több típussal 
ábrázolhassunk, valószínűleg célszerűbb a második megoldás mellett dönteni: 
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class XX : public X€/ ..."/); 


class XXX : public Xf/£ ...§/); 


void JO 

( 
C3t p1 - new C3(new X); // C3 "tartalmaz" egy X objektumot 
C3t p2 - new C3x(new XX); // C3 "tartalmaz" egy XX objektumot 
C3?t p3 - new C3(new XXX); // C3 "tartalmaz" egy XXX objektumot 
I esá 


j 


Itt nem lenne megfelelő ábrázolás, ha C3-at X-ből származtatnánk vagy ha C3-nak egy Xtí- 
pusú tagja lenne, mivel a tag pontos típusát kell használni. Ez a virtuális függvényekkel ren- 
delkező osztályoknál fontos, például egy alakzatosztálynál (§2.6.2) vagy egy absztrakt hal- 
mazosztálynál (425.3). 

A mutató tagokra épülő osztályok egyszerűsítésére azokban az esetekben, amikor a tartal- 
mazó objektum élettartama alatt csak egyetlen objektumra hivatkozunk, referenciákat 
használhatunk: 


class C4 (f 
X£ Tr; 
bublic: 
CA(Xxk a) : 1(g) ( ) 
/AKTB 
3 
Akkor is szükség van mutató és referencia típusú tagokra, amikor egy objektumon osztoz- 
ni kell: 


X" p - new XX; 
C4 objiCp); 
C4 obj2Cp9; // obj1 és obj2 most osztoznak az új XX objektumon 


Természetesen a közösen használt objektumok kezelése külön óvatosságot kíván, főleg 
a párhuzamos feldolgozást támogató rendszerekben. 


24.3.4. Tartalmazás és öröklés 


Az öröklési kapcsolatok fontosságának ismeretében nem meglepő, hogy ezeket a kapcso- 
latokat gyakran túlzottan használják vagy félreértik. Ha egy D osztály nyilvános és a B osz- 
tályból származtatott, gyakran azt mondjuk, hogy egy D valójában egy BD is a B: 
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class BEA... ?/); 
class D : public Bf / ...§/9; / D is a kind of B: D egyfajta B 


Úgy is kifejezhetjük, hogy az öröklés egy is-a kapcsolat, vagy — valamivel precízeb- 
ben -— hogy egy D valójában egyfajta B (D is a kind of B). Ezzel szemben ha a D osztály va- 
lamelyik tagja egy B osztály, azt mondjuk, hogy van (have) egy B-je, illetve tartalmaz 
(contain) egy B-t: 


class Df /D tartalmaz egy B-t 
bublic: 

B b; 

rzés 
J; 


Másképpen ezt úgy fejezzük ki, hogy a tagság egy has-a kapcsolat. 


Adott B és D osztályok esetében hogyan válasszunk öröklés és tagság között? Vegyünk egy 
Repülőgép-et és egy Motor-t. A kezdők gyakran kíváncsiak, jó ötlet-e egy Repülőgép osztályt 
a Motor-ból származtatni. Rossz ötlet, mert bár a repülőgépnek van motorja, a repülőgép 
nem motor. Vegyük figyelembe, hogy egy repülőgépnek kettő vagy több motorja is lehet. 
Mivel ésszerűnek látszik — még akkor is, ha az adott programban minden Repülőgép egy- 
motoros -, használjunk öröklés helyett tagságot. A , lehet-e neki kettő?" kérdés sok esetben 
hasznos lehet, ha kétség merül fel. Mint rendszerint, a programok megfoghatatlan termé- 
szete az, ami fontossá teszi ezt a vizsgálatot. Ha minden osztályt olyan könnyen elképzel- 
hetnénk, mint a Repülőgép-et és a Motor-t, könnyen elkerülhetnénk az olyan nyilvánvaló té- 
vedéseket, mint egy Repülőgép származtatása egy Motor-ból. Az ilyen tévedések azonban 
igen gyakoriak — különösen azoknál, akik a származtatást egyszerűen egy olyan eljárásnak 
tekintik, mellyel programozási nyelvi szintű szerkezeteket lehet együtt használni. Annak el- 
lenére, hogy az öröklés használata kényelmes és a kódot is rövidíti, majdnem kivétel nél- 
kül olyan kapcsolatok kifejezésére használjuk, melyeket a tervezésnél pontosan meghatá- 
roztunk. Vegyük a következőt: 


class Bf 

public: 

virtual void JO; 
void 90; 

3; 


class D1 ( // D1 tartalmaz egy B-t 

bublic: 

B b; 

void JO; // nem írja felül a b. fO virtuális függvényt 
j; 
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void hI(D1T" pd) 
t 
B? pb - pd; // hiba: nincs konverzió DT" -ról Bt -ra 
bb - gpd-b; 
bb-2g0; // B:g0 meghívása 
bd-2g0; // hiba: D1-nek nincs g0 tagja 
pd-ob.gO; 
bb-2fO; // B:fO meghívása (D1::fO nem írta felül) 
bd-fO; // D1::fO meghívása 


j 


Vegyük észre, hogy egy osztály nem konvertálható automatikusan (implicit módon) saját 
tagjává, és egy osztály, mely egy másik osztály egy tagját tartalmazza, nem írja felül a tag 
virtuális függvényeit. Ez ellentétes a nyilvános származtatással: 


class D2 : public Bf // D2 egy B 
bublic: 
void fO; // felülírja a B::fO virtuális függvényt 
HE 
void hXD2" pd) 
( 
B?" pb - pd; // rendben: automatikus konverzió D2" -ról B? -ra 
bb-2g0; // B:g0 meghívása 
bd-g0; // B::gO meghívása 
bb-ejfo; // virtuális hívás: D2::fO meghívása 
bd-2fO; // D2::fO meghívása 


A D2 példa a D1 példához képest kényelmesebb jelölést biztosít, és ez olyan tényező, ami 
a megoldás túlzott használatához vezethet. Emlékeztetni kell arra, hogy ezért a kényelemért 
a B és a D2 közti nagyobb függéssel kell fizetni (lásd §24.3.2.15. A D2-ről B-re történő au- 
tomatikus konverzióról különösen könnyű megfeledkezni. Hacsak az ilyen konverziók 
nem tartoznak szorosan a használt osztályok fogalomábrázolásához, kerüljük a public szár- 
maztatást. Ha egy osztályt egy fogalom ábrázolására használunk, az öröklés pedig is-a kap- 
csolatot fejez ki, szinte biztos, hogy éppen ilyen konverziókra lesz szükségünk. 


Vannak esetek, melyekben öröklést szeretnénk, de nem engedhetjük meg, hogy konverzió 
történjen. Vegyük egy G/ield osztály írását (controlled field, ellenőrzött mező), amely — 
egyebeken kívül - futási idejű hozzáférés-ellenőrzést biztosít egy másik Field osztály részé- 
re. Első ránézésre a Cfield meghatározása a Field-ből való származtatással éppen jónak 
látszik: 


class Cfield : public Field €/ ..."/); 
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Ez kifejezi, hogy egy Cfield valójában egyfajta Field, kényelmesebb jelölést biztosít, amikor 
olyan Cfield függvényt írunk, mely a Cfield Field részének egy tagját használja és — ez a leg- 
fontosabb — megengedi, hogy egy GCfield felülírja a Field virtuális függvényeit. Az a baj, hogy 
a Cfieldt-ról Field"-ra történő konverzió, amit a Cfield deklarációja sugall, meghiúsít min- 
den, a Field-hez való hozzáférés ellenőrzésére irányuló kísérletet: 


void e(Cfield" p) 
( 
kp - "asdf/; // a Field elérése a Cfield értékadó operátorával vezérelt: 
// pecCfield::operator-("asdf) 
Field" g - p; // automatikus átalakítás Cfield"-ről Field" -ra 
tg - "asdp; // hoppá! nincs Cfield-en keresztüli ellenőrzés 
J 


Egy megoldás az lehetne, hogy úgy határozzuk meg a Cfield-et, mint amelynek Field egy 
tagja, de ha ezt tesszük, eleve kizárjuk, hogy GCield felülírhassa Field virtuális függvényeit. 
Jobb megoldás, ha private öröklődést használunk: 


class Cfield : private Field €/£ ...§/ ); 


Tervezési szempontból a privát származtatás egyenértékű a tartalmazással, kivéve a felül- 
írás (alkalmanként lényeges) kérdését. E módszer fontos felhasználási területe egy osztály 
nyilvános származtatása egy felületet leíró absztrakt bázisosztályból, valamint a privát vagy 
védett származtatás egy konkrét osztályból, implementáció céljából (42.5.4, $12.3, 425.3. 
Mivel a private és protected származtatásból következő öröklődés nem tükröződik a szár- 
maztatott osztály típusában, néha implementációs öröklődésnek nevezzük a nyilvános szár- 
maztatással szemben, melynél a bázisosztály felülete öröklődik és az alaptípus automatikus 
konverziója megengedett. Az utóbbira néha mint altípuskészítésre (subtyping) vagy felület- 
öröklésre Gnterface inheritance) hivatkozunk. 


Úgy is megfogalmazhatjuk ezt, hogy rámutatunk, egy származtatott osztály objektuma hasz- 
nálható kell legyen mindenütt, ahol bázisosztályának objektumai használhatók. Ezt néha 
,Liskov-féle helyettesítési elvnek" (Liskov Substitution Principle) nevezik (§23.6 [Liskov, 
1987D. A nyilvános/védett/privát megkülönböztetés közvetlenül támogatja ezt, amikor 
többalakú típusokat mutatókon és hivatkozásokon keresztül kezelünk. 
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24.3.4.1. Tag vagy hierarchia? 


Hogy tovább vizsgáljuk a tartalmazást és öröklést magával vonó tervezési választásokat, ve- 
gyük egy gördítősáv (scrollbar) ábrázolását egy interaktív grafikus rendszerben és azt, ho- 
gyan kapcsolhatunk egy gördítősávot egy ablakhoz. Kétféle gördítősávra van szükségünk: 
vízszintesre és függőlegesre. Ezt két típussal ábrázolhatjuk — Horizontal scrollbar és 
Vertical scrollbar — vagy egyetlen olyan Scrollbar típussal, mely paraméterként megkapja, 
vízszintes vagy függőleges-e. Az előbbi választás következménye, hogy egy harmadik tí- 
pusra, a sima Scrollbar-ra is szükség van, mint a két gördítősáv-típus alaptípusára. Az utób- 
bi választás azt eredményezi, hogy egy külön paramétert kell használnunk és értékeket kell 
választanunk a két típus ábrázolására: 


enum Orientation f horizontal, vertical ) ; 


Választásunk meghatározza, milyen módosítások szükségesek a rendszer bővítéséhez. Le- 
het, hogy be kell vezetnünk egy harmadik típusú gördítősávot. Eredetileg úgy gondolhat- 
tuk, elég kétféle gördítősáv ( egy ablaknak végül is csak két dimenziója van"), de szinte 
minden esetben lehetségesek bővítések, melyek az újratervezés szükségességét vonják ma- 
guk után. Például lehet, hogy valaki a két gördítősáv helyett egy , navigáló gombot" szeret- 
ne használni. Egy ilyen gomb különböző irányú görgetést okozna, aszerint, hol nyomja meg 
a felhasználó. Felül középen nyomva , felfelé" görget, bal oldalon középen nyomva , balra", 
míg a bal felső sarkot nyomva ,balra felfelé". Az ilyen gombok nem szokatlanok. 
A gördítősávok továbbfejlesztett változatainak tekinthetők, és különösen illenek olyan 
programokhoz, melyekben a görgetett adatok nem csupán szövegek, hanem képek. 


Ha egy programba, melyben egy három gördítősávból álló osztályhierarchia van, egy navi- 
gáló gombot teszünk, létre kell hoznunk hozzá egy új osztályt, de a gördítősáv régi kódját 
nem kell módosítanunk: 


Scrollbar 


Horizontal scrollbar Vertical scrollbar Navigation button 
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Ez a , hierarchikus" megoldás szép oldala. 


Ha paraméterben adjuk meg a görgetés irányát, a gördítősáv-objektumokban típusmezők- 
nek, a gördítősáv-tagfüggvények kódjában pedig switch utasításoknak kell szerepelniük. Ez 
azt jelenti, hogy választanunk kell, deklarációk vagy kód által fejezzük ki a rendszer szer- 
kezetének ezt a vonását. Az előbbi növeli a statikus ellenőrzés fokát és azt az adatmennyi- 
séget, melyet az eszközöknek fel kell dolgozniuk. Az utóbbi a futási időre halasztja el a dön- 
téseket és az egyes függvények módosításával anélkül tesz lehetővé változtatásokat, hogy 
befolyásolná a rendszer átfogó szerkezetét a típusellenőrző és más eszközök szempontjá- 
ból. A legtöbb helyzetben azt javaslom, használjunk osztályhierarchiát a fogalmak kapcso- 
latainak közvetlen modellezésére. 


Az egyetlen típust használó megoldás megkönnyíti a gördítősáv fajtáját leíró adatok tárolá- 
sát és továbbítását: 


void helperCOrientation 00) 


f 
J/ ... 
bp - new Scrollbar(o09; 


Ve 
J 


void meO 


( 
helper(horizontaD; 


17 ss 
J 


Ez az ábrázolásmód megkönnyíti a görgetés irányának futási időben történő megváltoztatá- 
sát. Nem valószínű, hogy ennek itt nagy jelentősége van, de más hasonló példák esetében 
fontos lehet. A lényeg, hogy mindig választani kell, és a választás gyakran nem könnyű. 


24.3.4.2. Tartalmazás vagy hierarchia? 


Most vegyük azt a kérdést, hogyan kapcsoljunk egy gördítősávot egy ablakhoz. Ha egy 
Window with scrollbar-t úgy tekintünk, mint ami egyszerre Window és Scrollbar is, vala- 
mi ilyesmit kapunk: 


class Window with scrollbar : public Window, public Scrollbar f 
13 
j; 
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Ez megengedi, hogy egy Window with scrollbar úgy is viselkedhessen, mint egy Scrollbar 
és úgy is, mint egy Window, de arra kényszerít, hogy az egyetlen típust használó megoldást 
használjuk. 


Másrészt, ha a Window with scrollbar-t egy Scrollbar-ral rendelkező Window-nak tekint- 
jük, valami ilyesmit kapunk: 


class Window with scrollbar : public Window f 

set 

Scrollbar" sb; 
bublic: 

Window with scrollbar(Scrollbar? p, /£ ...?")) : Window(G .../), DD €/ ...?/) 

VZGSB 
b 
Ez megengedi, hogy a gördítősáv-hierarchia megoldást használjuk. Ha a gördítősávot para- 
méterben adjuk át, az ablak figyelmen kívül hagyhatja annak pontos típusát. Sőt, egy 
Scrollbar-t ahhoz hasonlóan is átadhatunk, ahogy az Orientation-t a §24.3.4.1 pontban. Ha 
arra van szükség, hogy a Window with scrollbar gördítősávként működjön, hozzátehe- 
tünk egy konverziós műveletet: 


Window with scrollbar::operator Scrollbark 


( 


return "sb; 


j 


Én azt részesítem előnyben, ha az ablak a gördítősávot tartalmazza. Könnyebb egy olyan 
ablakot elképzelni, melynek gördítősávja van, mint egy olyat, amely amellett, hogy ablak, 
még gördítősáv is. Kedvenc módszerem az, hogy olyan gördítősávot határozok meg, amely 
egy különleges ablak, és ezt tartalmazza egy, a gördítősáv-szolgáltatásokat igénylő ablak. 
Ez a tartalmazás használatát igényli, de emellett szól egy másik érv is, mely a ,lehet neki 
kettő is" szabályból következik (424.3.4). Mivel nincs logikus indok, miért ne lehetne egy 
ablaknak két gördítősávja (valójában sok ablaknak van vízszintes és függőleges is), nem kö- 
telező a Window with scrollbar-t a Scrollbar-ból származtatni. 


Vegyük észre, hogy ismeretlen osztályból nem lehet származtatni, fordításkor ismerni kell a 
bázisosztály pontos típusát (412.2). Másrészt, ha egy osztály egy tulajdonságát paraméter- 
ben adjuk át konstruktorának, akkor valahol az osztályban kell, hogy legyen egy tag, mely 
azt ábrázolja. Ha azonban ez a tag egy mutató vagy referencia, akkor a taghoz megadott 
osztályból származtatott osztály egy objektumát is átadhatjuk. Az előző példában például 
a Scrollbar" sb tagja mutathat egy olyan Scrollbar típusra, mint a Navigation button, amely 
a Scrollbar" felhasználója számára ismeretlen. 
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24.3.5. Használati kapcsolatok 


Annak ismerete, hogy egy osztály milyen más osztályokat használ és milyen módon, gyak- 
ran létfontosságú a programszerkezet kifejezése és megértése szempontjából. Az ilyen füg- 
géseket a Ct- csak rejtetten (implicit módon) támogatja. Egy osztály csak olyan elemeket 
használhat, melyeket (valahol) deklaráltak, de azok felsorolása nem szerepel a C-- forrás- 
kódban. Eszközök szükségesek (vagy megfelelő eszközök hiányában gondos elolvasás) az 
ilyen adatok kinyeréséhez. A módok, ahogy egy X osztály egy Y osztályt felhasználhat, 
többféleképpen osztályozhatók. Íme egy lehetséges változat: 


4 X használja az Ynevet. 
4 X használja Y1. 
e X meghívja Yegy tagfüggvényét. 
e Xolvassa Y egy tagját. 
e Xírja Y egy tagját. 
6 Xlétrehoz egy Y-t. 
e Xlefoglal egy auto vagy static Y változót. 
e Xa new segítségével létrehoz egy Y-t. 
$ veszi egy Y méretét. 


de független a konstruktoroktól. Az Y nevének használata szintén külön módszert jelent, 
mert ehhez önmagában - például egy Y" deklarálásánál vagy Y-nak egy külső függvény 
deklarációjában való említésénél — egyáltalán nem kell hozzáférni Y deklarációjához (§5.79: 


class Y; — /Y az osztály neve 
Y" DD; 
extern Y f((const Y£ ); 


Gyakran fontos, hogy különbséget tegyünk egy osztály felületének (az osztály deklaráció- 
jának) és az osztály megvalósításának függései között. Egy jól tervezett rendszerben az 
utóbbinak általában jóval több függősége van, és azok egy felhasználó számára sokkal ke- 
vésbé érdekesek, mint az osztály deklarációjának függései (424.4.2). A tervezéskor arra kell 
törekednünk, hogy a felületek függéseinek számát csökkentsük, mert ezekből az osztály 
felhasználóinak függései lesznek (48.2.4.1, 49.3.2, §12.4.1.1 és §24.4). 


A C44 nem kívánja meg egy osztály készítőjétől, hogy részletesen leírja, milyen más osztá- 
lyokat és hogyan használ fel. Ennek egyik oka, hogy a legjelentősebb osztályok oly sok más 
osztálytól függnek, hogy az olvashatóság miatt ezen osztályok rövidített felsorolására — pél- 
dául egy finclude utasításra — lenne szükség. A másik ok, hogy az ilyen függések osztályo- 
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zása nem a programozási nyelv kérdése. Az, hogy a , használja" (use) típusú függéseket 
pontosan hogyan szemléljük, függ a tervező, a programozó vagy az eszköz céljától, az pe- 
dig, hogy mely függések az érdekesek, függhet az adott fejlesztőkörnyezettől is. 


24.3.6. Beprogramozott kapcsolatok 


Egy programozási nyelv nem képes közvetlenül támogatni — és nem is szabad, hogy támo- 
gassa — minden tervezési módszer minden fogalmát. Hasonlóképpen egy tervezési nyelv- 
nek sem célszerű támogatnia minden programozási nyelv minden tulajdonságát. Egy terve- 
zési nyelv legyen gazdagabb és kevésbé törődjön a részletekkel, mint amennyire ez egy 
rendszerprogramozási nyelvnél szükséges. Megfordítva, egy programozási nyelvnek képes- 
nek kell lennie többféle tervezési filozófia támogatására, különben csorbul az alkalmazha- 
tósága. 


Ha egy programozási nyelvben nincs lehetőség egy tervezési fogalom közvetlen ábrázolá- 
sára, nem szabad hagyományos leképezést alkalmazni a tervezési szerkezetek és a progra- 
mozási nyelv szerkezetei között. A tervezési módszer például használhatja a delegálás 
(delegation) fogalmát, vagyis a terv meghatározhatja, hogy minden olyan műveletet, amely 
A osztályhoz nincs definiálva, egy p mutató által mutatott B osztálybeli objektum szolgáltas- 
son. A C4t- ezt nem tudja közvetlenül kifejezni, de rendelkezésre állnak olyan szerkezetek, 
melyek segítségével könnyű elképzelni egy programot, mely a fogalomból kódot hoz létre. 
Vegyük az alábbiakat: 


class Bf 
VAN 
void JO; 
void g0; 
void hO; 
2. 


J; 
class A (f 
B" p; 
Z-s 
void JO; 
void ffO; 
2. 


fi 


Annak meghatározása, hogy A osztály az 4::p mutatón keresztül átruházza ( delegálja") 
a feladatot B-re, ilyen kódot eredményezne: 
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class A f 
B" p; // delegálás p-n keresztül 
VAK 
void JO; 
void [f0; 
void g0 ( p-g0; ) // g0 delegálás 
void hO ( p--hO; // hO delegálás 
J; 


Egy programozó számára nyilvánvaló, hogy mi történik itt, de világos, hogy egy tervezési 
fogalom kóddal való utánzása kevesebb, mint valamely ,egy az egyhez" megfeleltetés. 
Az ilyen ,beprogramozott" kapcsolatokat a programozási nyelv nem , érti" olyan jól, ezért 
nehezebb azokat eszközökkel támogatni. A szabványos eszközök például nem ismernék 
fel, hogy az 4A::b-n keresztül A feladatát ruháztuk át B-re, nem pedig más célra használtuk 
a B"-ot. 


Ahol csak lehetséges, használjunk ,egy az egyhez" leképezést a tervezés és a programozá- 
si nyelv fogalmai között. Az ilyen leképezés biztosítja az egyszerűséget, és azt, hogy a prog- 
ram valóban tükrözi a tervezést, hogy a programozók és az eszközök hasznosíthassák an- 
nak fogalmait. A beprogramozott kapcsolatokkal rendelkező osztályok kifejezését a nyelv 
konverziós műveletekkel segíti. Ez azt jelenti, hogy az X::operator YO konverziós operátor 
meghatározza, hogy ahol elfogadható egy Y, ott használhatunk egy X-et is (§411.4.19. 
A Y:Y(X) konstruktor ugyanezt a kapcsolatot fejezi ki. Vegyük észre, hogy a konverziós 
operátorok (és a konstruktorok) új objektumokat hoznak létre, nem pedig létező objektu- 
mok típusát változtatják meg. Egy konverziós függvény deklarálása Y-ra nem más, mint egy 
Y-t visszaadó függvény rejtett alkalmazásának egy módja. Mivel a konstruktorok és 
konverziós operátorok által definiált átalakítások automatikus alkalmazása csalóka lehet, 
néha hasznos, ha a terven belül külön elemezzük azokat. 


Fontos, hogy biztosítsuk, hogy egy program konverziós diagramjai ne tartalmazzanak cik- 
lusokat. Ha tartalmaznak, az ebből adódó többértelműségek megakadályozzák, hogy a cik- 
lusokban szereplő típusokat együtt használhassuk: 


class Rational; 


class Big int (f 
bublic: 
friend Big int operatorá4(Big int,Big in0); 
operator RationalO; 
Mé 
j; 
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class Rational ( 

bublic: 
friend Rational operator: (Rational, Rational; 
operator Big intO; 
1 aa 


J; 
A Rational és a Big int típusok nem fognak olyan gördülékenyen együttműködni, mint 
remélnénk: 


void f((Rational r, Big inti) 


e(rxi);  // hiba, többértelmű: operatorá(r,Rationak()) vagy operatort(Big int(r)i) ? 
g(rtRational 09; // explicit feloldás 
2(Big int(r)31); // másik explicit feloldás 

) 


5 4 


Az ilyen , kölcsönös" konverziókat elkerülhetjük, ha legalább néhányat közülük explicitté 
teszünk. A Big int átalakítása Rational-lé például konverziós operátor helyett definiálható 
lett volna make Rational0-ként, az összeadást pedig g(Big int8),ij-re lehetett volna felol- 
dani. Ahol nem kerülhetők el az ilyen , kölcsönös" konverziók, a keletkezett ellentmondá- 
sokat vagy explicit átalakításokkal (lásd fen), vagy kétoperandusú operátorok (pl. --) több 
külön változatának deklarálásával kell feloldanunk. 


24.3.7. Osztályon belüli kapcsolatok 


Az osztályok a megvalósítás módját (és a rossz megoldásokat) csaknem teljes egészében el- 
rejthetik — és néha el is kell rejteniük. A legtöbb osztály objektumainak azonban szabályos 
szerkezete van és oly módon kezelhető, amit meglehetősen könnyű leírni. Egy osztály va- 
lamely objektuma alobjektumok (tagok) gyűjteménye, melyek közül sok más objektumok- 
ra mutat vagy hivatkozik. Egy objektum tehát úgy tekinthető, mint egy objektumfa gyöke- 
re, a benne szereplő objektumok pedig mint egy , objektum-hierarchia" alkotóelemei, ami 
az osztályhierarchia kiegészítője (lásd 25.3.2.19. Vegyünk például egy nagyon egyszerű 
String-et: 


class String f 
int Sz; 
char" p; 
bublic: 
String(const char" 9); 
-StringO; 
HZAKOB 


J; 
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Egy String objektum grafikusan így ábrázolható: 








Mei . ..elemek...NO 











int sz ; 
char" p ; 47 











24.3.7.1. Invariánsok 


A tagok és a tagok által hivatkozott objektumok értékeit gyűjtőnéven az objektum állapo- 
tának (vagy egyszerűen értékének) nevezzük. Egy osztály tervezésénél fontos az objektu- 
mok pontosan definiált állapotba hozása (kezdeti értékadás/létrehozás), ezen állapot fenn- 
tartása a műveletek végrehajtása során, és végül az objektumok megfelelő megsemmisítése. 
Az a tulajdonság, amely pontosan definiáltá teszi egy objektum állapotát, az objektum in- 
variánsa (állapotbiztosítója, invariant). 


A kezdeti értékadás célja tehát az objektumot abba az állapotba helyezni, amelyet az 
invariáns leír. Ezt általában egy konstruktorral végezzük. Egy osztályon végzett minden mű- 
velet feltételezheti, hogy belépéskor érvényesnek találja az állapotot (vagyis hogy az inva- 
riáns logikai értéke igaz) és kilépéskor ugyanez a helyzet áll fenn. Az invariánst végül 
a destruktor érvényteleníti, az objektum megsemmisítésével. A String::String(const char?) 
konstruktor például biztosítja, hogy p egy legalább szt7 elemű tömbre mutat, ahol sz-nek 
értelmes értéke van és p/sz/--0O. Ezt az állítást minden karakterlánc-műveletnek , igaznak" 
kell hagynia. 


Az osztálytervezésben a legtöbb szakértelem ahhoz kell, hogy az adott osztályt elég egysze- 
rűvé tegyük, hogy használható, egyszerűen kifejezhető invariánssal valósíthassuk meg. 
Elég könnyű kijelenteni, hogy minden osztálynak szüksége van invariánsra. Ami nehéz, egy 
használható invariánssal , előhozakodni", amely könnyen érthető és nem jár elfogadhatat- 
lan megszorításokkal a készítőre vagy a műveletek hatékonyságára vonatkozóan. Vegyük 
észre, hogy az , invariánst" itt egy olyan kódrészlet megjelölésére használjuk, melyet futtat- 
hatunk egy objektum állapotának ellenőrzésére. Világos, hogy be lehetne vezetni egy szi- 
gorúbb, , matematikaibb" és — bizonyos környezetben — megfelelőbb fogalmat is. AZ inva- 
riáns, ahogyan itt tárgyaljuk, az objektum állapotának egyfajta gyakorlati — és emiatt 
általában gazdaságos, de logikailag nem tökéletes — ellenőrzése. 
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Az invariáns fogalma Floyd, Naur és Hoare előfeltételekkel és utófeltételekkel foglalkozó 
munkáiból ered és lényegében minden absztrakt adattípusokról és programhelyesség-el- 
lenőrzésről szóló munka említi, amit az utóbbi 30 évben írtak, így a C hibakeresésnek is 
fontos elemét képezi. Az invariáns ellenőrzésére a tagfüggvények végrehajtása közben ál- 
talában nem kerül sor. Azok a függvények, melyek meghívhatók, miközben az invariáns ér- 
vénytelen, nem lehetnek a nyilvános felület részei; e célra a privát és védett függvények 
szolgálhatnak. 


Hogyan fejezhetjük ki egy C-- programban az invariáns fogalmát? Erre egy egyszerű mód 
egy invariáns-ellenőrző függvényt megadni és a nyilvános műveletekbe e függvény meghí- 


vását beiktatni: 


class String f 


int Sz; 
char" p; 

bublic: 
class Range (7; // kivételosztály 
class Invariant (7 ; // kivételosztály 
enum f TOO LARGE - 16000 2; // mérethatár 


void checkO; 


String(const char"? 9); 
String(const Stringf ); 
-StringO; 


chark operatorí[Gnt i); 
int sizeO f return sz; ) 


Mae. 


J; 


void String::checkO 
( 


// állapot-ellenőrzés 


if (p--o II szc0o II TOO LARGESsS-sz 11 piszD throw InvariantO; 
) 


J 


charg String::operatorí[ (int i) 


( 
checkO; 


if G20 11 szc-i) throw RangeO; 
// itt végezzük a tényleges munkát 


checkO; 
return plil; 


// ellenőrzés belépéskor 


// ellenőrzés kilépéskor 
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Ez szépen fog működni és alig jelent munkát a programozó számára. Viszont egy egyszerű 
osztálynál, mint a Sztring, az állapotellenőrzés döntően befolyásolja a futási időt és lehet, 
hogy még a kód méretét is. Ezért a programozók gyakran csak hibakeresés alatt hajtják vég- 
re az invariáns ellenőrzését: 


inline void String::checkO 


( 
seifndef NDEBUG 
if (p--o II szo II 700 LARGES-sz 11 piszD throw InvariantO; 
endif 
J 


Itt az MDEBUG makrót használjuk, hasonló módon, mint ahogy azt a szabványos C assertO 
makró használja. Az NDEBUG rendszerint azt jelzi, hogy nem történik hibakeresés. 


Az invariánsok megadása és hibakeresés alatti használata felbecsülhetetlen segítséget jelent 
a kód , belövésénél" és — ami még fontosabb - akkor, amikor az osztályok által ábrázolt fo- 
galmakat pontosan meghatározottá és szabályossá tesszük. A lényeg az, hogy az invarián- 
sok beépítésével az osztályokat más szempontból vizsgálhatjuk és a kódban ellenőrzést he- 
lyezhetünk el. Mind a kettő növeli a valószínűségét, hogy megtaláljuk a hiányosságokat, 
következetlenségeket és tévedéseket. 


24.3.7.2. Feltételezések 


Az invariáns kód egyfajta feltételezés (assertion), ami viszont nem más, mint annak a kije- 
lentése, hogy egy adott logikai feltételnek teljesülnie kell. Az a kérdés, mit kell tenni, ami- 
kor nem teljesül. 


A C standard könyvtára - és következésképpen a C-t standard könyvtára — tartalmazza az 
assertO makrót a Ccassert:-ben vagy cassert.h:-ban. Az assertO kiértékeli a paraméterét és 
meghívja az abortO-ot, ha az eredmény nulla (vagyis , hamis"): 


void fint" p) 

( 
assert(p!1-0)9; // feltételezi, hogy p/!-O; abortO meghívása, ha p nulla 
Vt 

J 


A program megszakítása előtt az assertO kiírja saját forrásfájljának nevét és annak a sornak 
a számát, amelyben előfordult. Ezáltal az assertÖ hasznos hibakereső eszközt jelent. 
Az NDEBUG beállítása rendszerint fordítói utasítások segítségével történik, fordítási egysé- 
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genként. Ebből következik, hogy az assertO használata tilos olyan helyben kifejtett (inline) 
függvényekben és sablon függvényekben, melyek több fordítási egységben is előfordul- 
nak, hacsak nem fordítunk igen nagy gondot az VDEBUG következetes beállítására (49.2.3). 
Mint minden , makró-varázslat", az NDEBUG használata is túl alacsony szintű, rendetlen és 
hibaforrást jelenthet. Általában jó ötlet, ha még a legjobban ellenőrzött programban is ha- 
gyunk néhány ellenőrző kódot; az NDEBUG viszont erre nem nagyon alkalmas, és az 
abortO meghívása is ritkán fogadható el a végleges kódban. 


A másik megoldás egy AssertO sablon használata, mely a programból való kilépés helyett 
egy kivételt vált ki, így kívánságra a végleges kódban bennmaradhatnak az ellenőrzések. 
Sajnos a standard könyvtár nem gondoskodik ilyen Assert0-ről, de mi könnyen elkészíthet- 
jük: 


templatexciass X, class A: inline void Assert(A assertion) 


( 
if ("assertion) throw XO); 


J 


Az AssertO egy XO kivételt vált ki, ha az assertion hamis: 


class Bad arg ); 


void fint"p) 

( 
AssertSBad argr:(p!-O); — / feltételezi, hogy p!/-O; Bad arg kivételt vált ki, hacsak p/-O 
Vvsse 


j 


Az ellenőrzésben a feltételt pontosan meg kell határoznunk, tehát ha csak hibakeresés alatt 
akarunk ellenőrizni, jeleznünk kell e szándékunkat: 


void f2Xint" p) 
( 
AssertkBad argx(NDEBUG 11 p/-0);  // vagy nem hibakeresés folyik vagy p!-O 
1 
) 
A 11 használata az ellenőrzésben ££ helyett meglepőnek tűnhet, de az AssertSE: (al 1b) 


a (al 11DJ-t ellenőrzi, ami /adk £/b. 


Az NDEBUGilyen módon való használata megköveteli, hogy az NDEBUG-nak megfelelő ér- 
téket adjunk, aszerint, hogy akarunk-e hibakeresést végezni vagy sem. A C-t- egyes válto- 
Zatai alapértelmezés szerint nem teszik ezt meg nekünk, ezért jobb saját értéket használni: 
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itifdef NDEBUG 

const bool ARG CHECK - false; // nem hibakeresés: ellenőrzés kikapcsolása 
itelse 

const bool ARG CHECK - true; // hibakeresés 

íendif 


void f3(int" p) 
( 
AssertkBad arg:(JARG CHECK 11 p/-09; // vagy nem hibakeresés folyik vagy p/-O 


VESE 
J 


Ha egy ellenőrzéssel kapcsolatos kivételt nem kapunk el, az AssertO leállítja a programot 
(terminateO), hasonlóan ahhoz, ahogyan a megfelelő assertO abortO-tal járna. Egy kivétel- 
kezelő azonban képes lehet valamilyen kevésbé durva beavatkozásra. 


A valóságos méretű programokban azon veszem észre magamat, hogy egyes csoportokban 
be- és kikapcsolom a feltételezéseket, aszerint, hogy kell-e tesztelni. Ennek az eljárásnak az 
NDEBUG használata a legnyersebb formája. A fejlesztés elején a legtöbb ellenőrzés be van 
kapcsolva, míg az átadott kódban csak a legfontosabbak megengedettek. Ez akkor érhető 
el a legkönnyebben, ha a tényleges ellenőrzések két részből állnak, ahol az első egy meg- 
engedő feltétel (mint az ARG. CHECK), és csak a második maga a feltételezés. 


Amennyiben a megengedő feltétel konstans kifejezés, az egész ellenőrzés kimarad a fordí- 
tásból, ha nincs bekapcsolva. Lehet azonban változó is, mely a hibakeresés szükségletei 
szerint futási időben be- és kikapcsolható: 


bool string check -— true; 


inline void String::checkO 
( 
AssertéInvariant(!string check II] (bp £k 0£-sz ££k szcTOO LARGE £é£ plsz[--099; 


J 


void JO 
f 
String s - "csoda"; 
// a karakterláncokat itt ellenőrizzük 
string check - false; 
// itt a karakterláncokat nem ellenőrizzük 


J 
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Természetesen ilyen esetekben létrejön a megfelelő programkód, tehát ügyelnünk kell, ne- 
hogy a program , meghízzon" az ilyen ellenőrzések kiterjedt használatától. 


Ha azt mondjuk: 


AssertZE:(a); 


az egyszerűen egy másik módja ennek: 


if (a) throw EO; 


Így viszont felmerül a kérdés: minek bajlódjunk az Assert0-tel az utasítás közvetlen kiírása 
helyett? Azért, mert az AssertO0 használata nyilvánvalóvá teszi a tervező szándékát. Azt feje- 
zi ki, hogy valamiről feltételezzük, hogy mindig igaz. Ez nem a program logikájának lényeg- 
telen része, hanem értékes információ a program olvasója számára. Gyakorlati előnye, hogy 
egy assertO-et vagy Assert0-et könnyű megtalálni, míg a kivételeket kiváltó feltételes utasí- 
tásokat nehéz. 


Az AssertO általánosítható olyan kivételek kiváltására is, melyek paramétereket vagy kivé- 
tel-változókat vehetnek át: 


templatexcliass A, class E: inline void Assert(A assertion, E excepb) 


( 


if ("assertion) throw except; 


J 


struct Bad g arg ( 

int" p; 

Bad g arg(int" pp) : b(pp) ( ) 
iz 


Jo 


bool g check - true; 
intg max — 100; 


void g(int" p, exception e) 


( 
Assert(ig check 11 p/-0O, e; // a mutató érvényes 
Assert(ig check II (O£pkk£pc-g max) Bad g arg(p)); // az érték ésszerű 
s 


j 


Sok programban döntő fontosságú, hogy ne jöjjön létre kód olyan AssertO esetén, ahol az 
ellenőrzés a fordítás során kiértékelhető. Sajnos egyes fordítók az általánosított AssertO-nél 
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ezt képtelenek elérni. Következésképpen a kétparaméterű AssertO-et csak akkor használ- 
juk, ha a kivétel nem FO alakú vagy ha valamilyen, az ellenőrzött értéktől független kódot 
kell készíteni. 


A §23.4.3.5 pontban említettük, hogy az osztályhierarchia átszervezésének két legközönsé- 
gesebb formája az osztály kettéhasítása, illetve két osztály közös részének kiemelése egy 
bázisosztályba. Az átszervezés lehetőségét mindkét esetben megfelelő invariánsokkal biz- 
tosíthatjuk. Viszont ha összehasonlítjuk az invariánst a műveletek kódjával, egy , hasításra 
érett" osztályban az állapotellenőrzést fölöslegesnek találhatjuk. Ilyen esetekben a művele- 
tek részhalmazai csak az objektum állapotának részhalmazaihoz fognak hozzáférni. Meg- 
fordítva, azok az osztályok, melyek összefésülhetők, hasonló invariánsokkal rendelkeznek 
akkor is, ha megvalósításuk különbözik. 


24.3.7.3. Előfeltételek és utófeltételek 


A feltételezések (asser9) egyik népszerű használata egy függvény előfeltételeinek és utófel- 
tételeinek kifejezése. Ez azt jelenti, hogy ellenőrizzük a bemenetre vonatkozó alapfeltétele- 
zések érvényességét és azt, hogy kilépéskor a függvény a programot a várt állapotban hagy- 
ja-e. Sajnos amit a feltételezéssel ki szeretnénk fejezni, gyakran magasabb szinten van, mint 
aminek a hatékony kifejezésére a programozási nyelv lehetőséget ad: 


templatexclass Ran: void sort(Ran first, Ran lasb) 


( 


AssertSBad seguence-("A (first, last) érvényes sorozat"); // álkód 
// ... rendező algoritmus ... 


AssertsFailed sort-("A (first, las) növekvő sorrendű");  // álkód 


J 


Ez alapvető probléma. Amit egy programról feltételeztink, az matematikai alapú, magasabb 
szintű nyelven fejezhető ki a legjobban, nem azon az algoritmusokra épülő programozási 
nyelven, amelyben a programot írjuk. 


Az invariánsok meghatározásához hasonlóan a feltételezések megfogalmazása is bizonyos 
fokú ügyességet igényel, mert az ellenőrizni kívánt állítást úgy kell megadnunk, hogy az 
egy algoritmussal valóban ellenőrizhető legyen: 
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templatezclass Ran: void sort(Ran first, Ran las) 


( 
// A (first last) érvényes sorozat; a hihetőség ellenőrzése: 
AssertSBad seguencex(NDEBUG 1!1 firstc-las)); 


// ... rendező algoritmus ... 


// A (first last) növekvő sorrendű; próba-ellenőrzés: 
AssertsFailed sort-(NDEBUG 11 
(dast-firstz2 11 Cfirsts-last[-1/ 
kk "firstszfirst[(rdast-firsD/2] k £ firstí(last-firsty21c-last[-1D)9; 


j 


Én gyakran egyszerűbbnek találom a közönséges kódellenőrző paraméterek és eredmé- 
nyek használatát, mint a feltételezések összeállítását. Fontos azonban, hogy megpróbáljuk 
a valós Gdeális) elő- és utófeltételeket kifejezni — és legalább megjegyzések formájában do- 
kumentálni azokat — mielőtt olyan, kevésbé absztrakt módon ábrázolnánk, ami a programo- 
zási nyelven hatékonyan kifejezhető. 


Az előfeltételek ellenőrzése könnyen egyszerű paraméterérték-ellenőrzéssé fajulhat. Mivel 
a paraméterek gyakran több függvényen keresztül adódnak át, az ellenőrzés ismétlődővé 
és költségessé válhat. Annak az egyszerű kijelentése azonban, hogy minden függvényben 
minden mutató-paraméter nem nulla, nem sokat segít, és hamis biztonságérzetet adhat — 
különösen akkor, ha a többletterhelés elkerülése végett az ellenőrzéseket csak hibakeresés 
alatt végezzük. Ez az egyik fő oka, hogy javaslom, fordítsunk figyelmet az invariánsokra. 


24.3.7.4. Betokozás 


Vegyük észre, hogy a C4--ban az osztályok — nem az egyes objektumok - a betokozás 
(enkapszuláció, encapsulation) alapegységei: 


class List f 
List" next; 
bublic: 
bool on(list",; 
ZER 


J; 


bool List::on(List" p) 

( 
if (pb -- 0) return false; 
fordist" ag - this; g; g-g-2nexn if (p --— a) return true; 
return false; 


j 
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A privát List::next mutató betokozása elfogadható, mivel a List::on0 hozzátér a List osztály 
minden objektumához, amelyre hivatkozni tud. Ahol ez kényelmetlen, egyszerűsíthetünk, 
ha nem használjuk ki azt a képességet, hogy egy tagfüggvényből más objektumok ábrázo- 
lásához hozzá lehet férni: 


bool List::on(List" p) 

f 
if (p -—- 0) return false; 
if (p -— this) return true; 
if (next--0) return false; 
return next-2o(DJ; 


J 


Ez azonban a bejárást (iteráció) ismétléssé (rekurzióvá) alakítja át, ami komoly teljesít- 
ményromlást okozhat, ha a fordító nem képes az optimális működéshez az eljárást vissza- 
alakítani. 


24.4. Komponensek 


A tervezés egységei az osztályok, függvények stb. gyűjteményei, nem egy egyes osztályok. 
Ezeket a gyűjteményeket gyakran könyvtárnak (ibrary) vagy keretrendszernek 
(framework) nevezzük (425.8), és az újrahasznosítás (423.5.1) és karbantartás is ezeket he- 
lyezi a középpontba. A logikai feltételek által összekapcsolt szolgáltatások halmazát jelen- 
tő fogalom kifejezésére a C-t három módot biztosít: 


1. Osztály létrehozása, mely adat-, függvény-, sablon- és típustagok gyűjteményét 
tartalmazza. 

2. Osztályhierarchia létrehozása, mely osztályok gyűjteményét foglalja magában. 

3. Névtér meghatározása, mely adat-, függvény-, sablon- és típustagok gyűjtemé- 
nyéből áll. 


Az osztályok számos lehetőséget biztosítanak arra, hogy kényelmesen hozhassunk létre ál- 
taluk meghatározott típusú objektumokat. Sok jelentős komponens azonban nem írható le 
úgy, mint adott típusú objektumokat létrehozó rendszer. Az osztályhierarchia egymással ro- 
kon típusok halmazának fogalmát fejezi ki. A komponensek egyes tagjainak kifejezésére 
azonban nem mindig az osztályok jelentik a legjobb módszert és nem minden osztály il- 
leszthető hasonlóság alapján osztályhierarchiába (424.2.59. Ezért a komponens fogalmának 
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a C44-ban a névtér a legközvetlenebb és legáltalánosabb megtestesítése. A komponense- 
ket néha , osztálykategóriáknak" nevezzük, de nem minden esetben állnak osztályokból (és 


ez nem is előírás). 


Ideális esetben egy komponens a megvalósítására használt felületekkel, valamint azokkal 
a felületekkel írható le, melyeket felhasználói részére biztosít. Minden más , részletkérdés" 
és a rendszer többi része számára rejtett. A tervező szemszögéből ez a komponens megha- 
tározása. A programozó ezt a fogalmat deklarációkra leképezve ábrázolhatja. Az osztályok 
és osztályhierarchiák adják a felületeket, melyek csoportosítására a névterek adnak lehető- 
séget, és ugyancsak a névterek biztosítják, hogy a programozó elválaszthassa a felhasznált 


felületeket a szolgáltatottaktól. Vegyük az alábbi példát: 


X felülete által használt 








X felülete 








X megvalósítása 





A §8.2.4.1-ben leírt módszerek felhasználásával ebből az alábbi lesz: 


namespace A ( 


V/4ta 


j 


namespace X f 


using namespace A; 


// ... 
void JO; 
) 


namespace X implf 


using namespace X; 


Ms 


J 


// az X felülete által használt szolgáltatások 


// az X komponens felülete 


// az A deklarációitól függ 


// az X megvalósításához szükséges szolgáltatások 


X megvalósítása által használt 
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void X::fO 

( 
using namespace X impl; // az X impl deklarációitól fiigg 
Ms 

J 


Az X általános felület nem függhet az X impl megvalósítási felülettől. 


Egy komponensnek számos olyan osztálya lehet, melyek nem általános használatra szán- 
tak. Az ilyen osztályokat megvalósító osztályokba vagy névterekbe kell , elrejteni" : 


namespace X. impl( // az X megvalósításának részletei 


class Widget ( 
VES 
5 


Vá 
J 


Ez biztosítja, hogy a Widget-et nem használhatjuk a program más részeiből. Az egységes fo- 
galmakat ábrázoló osztályok általában újrahasznosíthatók, ezért érdemes befoglalni azokat 
a komponens felületébe: 


class Car ( 
class Wheel f 
éa 
si 


Wheel flw, frw, rlw, TTw; 
as 

bublic: 
VAN 

J; 


A legtöbb környezetben el kell rejtenünk a kerekeket ( WhieeD, hogy megtartsuk az autó 
( Car) ábrázolásának pontosságát (egy valódi autó esetében sem tudjuk a kerekeket függet- 
lenül működtetni). Maga a Wheel osztály viszont alkalmasnak tűnik szélesebb körű haszná- 
latra, így lehet, hogy jobb a Car osztályon kívülre tenni: 


class Wheel f 
Tsz 
VA 
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class Car f 

Wheel flw, frw, rlw, Trw; 

lna 
bublic: 

A a 
Pi 
A döntés, hogy beágyazzuk-e az egyik fogalmat a másikba, attól függ, mik a tervezés céljai 
és mennyire általánosak a fogalmak. Mind a beágyazás, mind a , nem beágyazás" széles kör- 
ben alkalmazható módszer. Az alapszabály az legyen, hogy az osztályokat a lehető legönál- 
lóbbá ( helyivé") tesszük, amíg általánosabb elérésüket szükségesnek nem látjuk. 


Az , érdekes" függvényeknek és adatoknak van egy kellemetlen tulajdonsága, mégpedig az, 
hogy a globális névtér felé, a széles körben használt névterekbe vagy a hierarchiák gyökér- 
osztályaiba , törekednek". Ez könnyen vezethet a megvalósítás részleteinek nem szándékos 
nyilvánossá tételéhez és a globális adatokkal és globális függvényekkel kapcsolatos prob- 
lémákhoz. Ennek valószínűsége az egyetlen gyökerű hierarchiákban és az olyan progra- 
mokban a legnagyobb, ahol csak nagyon kevés névteret használunk. E jelenség leküzdésé- 
re az osztályhierarchiákkal kapcsolatban a virtuális bázisosztályokat (415.2.4) használhatjuk 
fel, a névtereknél pedig a kis ,implementációs" névterek kialakítása lehet megoldás. 


Megjegyzendő, hogy a fejállományok (header) komoly segítséget nyújthatnak abban, hogy 
a komponenseket felhasználóiknak különböző szempontból , mutathassuk", és kizárják 
azokat az osztályokat, melyek a felhasználó szempontjából a megvalósítás részeinek tekint- 
hetők (49.3.29. 


24.4.1. Sablonok 
A tervezés szempontjából a sablonok (template) két, laza kapcsolatban lévő szükségletet 
szolgálnak ki: 


e — Általánosított (generic) programozás 
e — Eljárásmódot (policy) meghatározó paraméterezés 


A tervezés korai szakaszában a műveletek csupán műveletek. Később, amikor az 
operandusok típusát meg kell határozni, az olyan, statikus típusokat használó programozá- 
si nyelvekben, mint a C4--, a sablonok lényeges szerepet kapnak. Sablonok nélkül a függ- 
vény-definíciókat újra meg újra meg kellene ismételni, vagy az ellenőrzéseket a futási idő- 
re kellene elhalasztani (424.2.39. Azokat a műveleteket, amelyek egy algoritmust többféle 
operandustípusra kell, hogy leírjanak, célszerű sablonként elkészíteni. Ha az összes ope- 
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randus egyetlen osztályhierarchiába illeszthető (és különösen akkor, ha futási időben szük- 
ség van új operandustípusok hozzáadására is), az operandustípusok osztályként, mégpedig 
általában absztrakt osztályként ábrázolhatók a legjobban. Ha az operandustípusok nem il- 
lenek bele egyetlen hierarchiába (és különösen akkor, ha a futási idejű teljesítmény létfon- 
tosságú), a műveletet legjobb sablonként elkészíteni. A szabványos tárolók és az azokat tá- 
mogató algoritmusok annak példái, amikor a többféle, nem rokon típusú operandus 
használatának és a futási idejű teljesítmény fokozásának egyidejű szükségessége vezet sab- 
lonok használatához (§16.2). Vegyük egy egyszerű bejárás általánosítását, hogy jobban 
szemügyre vehessük a , sablon vagy hierarchia?" dilemmát: 


void print all(Iter. for. T x) 


for (1T"p - x firstO; p; b - x.next0) cout c "p; 
J 


Itt azzal a feltételezéssel éltünk, hogy az Iter for. T olyan műveleteket biztosít, melyek 
Ttokat hoznak létre. 


Az Iter. for. T-t sablonparaméterré tehetjük: 
templateccliass Iter. for. T- void print all(iter. for. T x) 


for (1T"p - x firstO; p; b - x.next0) cout c£ "p; 
J 


Ez lehetőséget ad arra, hogy egy sereg egymással nem rokon bejárót (iterator) használjunk, 
ha ezek mindegyike biztosítja a helyes jelentésű /irst0-öt és next0-et és ha fordítási időben 
minden print all0 hívás bejárójának típusát ismerjük. A standard könyvtár tárolói és algo- 


ritmusai ezen az ötleten alapulnak. 


Felhasználhatjuk azt a megfigyelést is, hogy a /firstO és a nextO a bejárók számára felületet 
alkotnak és létrehozhatunk egy osztályt, amely ezt az felületet képviseli: 


class Iter f 

bublic: 
virtual T" firstŐ const — 0; 
virtual T" nextŐ — O; 


Kés 
void print allldterk x) 


for (1"p - x firstO; p; pb - x.next0) cout c£ "p; 
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Most már az Iter-ből származtatott valamennyi bejárót használhatjuk. A kódok azonosak, 
függetlenül attól, hogy sablonokat vagy osztályhierarchiát használunk a paraméterezés áb- 
rázolására — csak a futási idő, újrafordítás stb. tekintetében különböznek. Az Iter osztály kü- 
lönösen alkalmas arra, hogy az alábbi sablon paramétere legyen: 


void flterg i) 
( 


print all(0; // a sablon használata 
print all20); 
? 


af 


Következésképpen a két megközelítés egymást kiegészítőnek tekinthető. 


Egy sablonnak gyakran van szüksége arra, hogy függvényeket és osztályokat úgy használ- 
jon, mint megvalósításának részeit. Soknak közülük maguknak is sablonoknak kell lenni- 
ük, hogy megtartsuk az általánosságot és a hatékonyságot. Így az algoritmusok több típus- 
ra általánosíthatók. A sablonok használatának ezt a módját nevezzük általánosított vagy 
generikus bprogramozásnak (§2.7). Ha az std::sortO-ot egy vector-ra hívjuk meg, a sortO 
operandusai a vektor elemei lesznek, vagyis a sort0 az egyes elemtípusokra általánosított. 
A szabványos rendező függvény emellett általános a tárolótípusokra nézve is, mert bár- 
mely, a szabványhoz igazodó tároló bejárójára meghívható (§16.3.1). 


A sortO algoritmus az összehasonlítási feltételekre is paraméterezett (418.7.1). Tervezési 
szempontból ez más, mint amikor veszünk egy műveletet és általánosítjuk az operandus tí- 
pusára. Sokkal magasabb szintű tervezési döntés, hiszen egy objektumon (vagy műveleten) 
dolgozó algoritmust úgy paraméterezünk, hogy az az algoritmus működésmódját vezérli. 
Ez egy olyan döntés, ami részben a tervező/programozó kezébe adja a vezérlést az algorit- 
mus működési elveinek kialakításában. 


24.4.2. Felület és megvalósítás 
Az ideális felület 


e teljes és egységes fogalomkészletet ad a felhasználónak, 

s a komponensek minden részére nézve következetes, 

e nem fedi fel a megvalósítás részleteit a felhasználónak, 

e többféleképpen elkészíthető, 

e típusai fordítási időben ellenőrizhetők, 

e alkalmazásszintű típusok használatával kifejezett, 

e más felületektől korlátozott és pontosan meghatározott módokon függ. 
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Miután megjegyeztük, hogy az osztályok között, melyek a külvilág felé a komponens felü- 
letét képezik, következetességre van szükség (424.4), a tárgyalást egyetlen osztályra egysze- 


rűsíthetjük. Vegyük az alábbi példát: 
class Y€/5... 7); // X által igényelt 
class Z€/5... 7); // X által igényelt 


class Xf / példa a szegényes felületre 
Y a; 
Z b; 
bublic: 
void Kconst char ? ...); 
void g(int[[ int; 
void set a(Y£ ); 
Yk get aO; 
a 


Ennél a felületnél több probléma is felmerülhet: 


e Afelület Yés Ztípust úgy használja, hogy a fordítónak ismernie kell Yés Z 
deklarációját. 

e Az X::fÖ függvény tetszőleges számú ismeretlen típusú paramétert vehet át 
(valószínűleg egy, az első paraméterben megkapott , formázott karakterlánc" 
által vezérelt módon, §21.8). 

e Az X::g0 egy int/] paramétert vesz át. Ez elfogadható lehet, de annak a jele, 
hogy az elvonatkoztatás szintje túl alacsony. Egy egészekből álló tömb nem 
önleíró, tehát nem magától értetődő, hány eleme van. 

e Aset adés get a0 függvények valószínűleg felfedik X osztály objektumainak 
ábrázolását, azáltal, hogy X::a-hoz közvetlen hozzáférést tesznek lehetővé. 


Ezek a tagfüggvények nagyon alacsony elvonatkoztatási (fogalmi) szinten nyújtanak felüle- 
tet. Az ilyen szintű felületekkel rendelkező osztályok lényegében egy nagyobb komponens 
megvalósításának részletei közé tartoznak — ha egyáltalán tartoznak valahová. Ideális eset- 
ben egy felületfüggvény paramétere elég információt tartalmaz ahhoz, hogy önleíró legyen. 
Alapszabály, hogy a kérelmek , vékony dróton át" legyenek továbbíthatóak a távoli kiszol- 
gáló felé. 


A C44 a programozónak lehetőséget ad arra, hogy az osztályokat a felület részeként ábrá- 
zolja. Az ábrázolás lehet rejtett (private vagy protected használatával), de a fordító megen- 
gedi automatikus változók létrehozását, függvények helyben kifejtését stb. is. Ennek nega- 
tív hatása, hogy az osztálytípusok használata az osztály ábrázolásában nemkívánatos 
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függéseket idézhet elő. Az, hogy probléma-e Yés Ztípusok tagjainak használata, attól függ, 
valójában milyen fajta típus Yés Z. Ha egyszerű típusok, mint a list, a complex vagy a string, 
használatuk általában teljesen megfelelő. Az ilyen típusok stabilnak minősülnek és osztály- 
deklarációik beépítése a fordító részére elfogadható terhelés. Ha azonban Yés Z maguk is 
jelentős komponensek (például egy grafikus rendszer vagy egy banki kezelőrendszer osz- 
tályai), bölcsebb lenne, ha nem függnénk tőlük túl közvetlenül. Ilyen esetekben gyakran 
jobb választás egy mutató vagy referencia használata: 


class Y; 
class Z; 


class Xf /.X csak mutatón és referencián át éri el Y-t és Z-t 
Y" a; 
za b; 
Zs 


J; 


Ez leválasztja X definícióját Y és Z definícióiról, vagyis X definíciója csak Yés Z nevétől 
függ. X megvalósítása természetesen még mindig függ Yés Z definíciójától, de ez nem érin- 
ti X felhasználóit. 


Ezzel egy fontos dolgot szemléltettünk: egy felületnek, mely jelentős adatmennyiséget rejt 
el — ahogyan ez egy használható felülettől elvárható — sokkal kevesebb lesz a függése, mint 
az általa elrejtett megvalósításnak. Az X osztály definíciója például anélkül fordítható le, 
hogy Yés Z definícióihoz hozzáférnénk. A függések elemzésekor külön kell kezelni a felü- 
let és külön a megvalósítás függéseit. Mindkét esetben ideális, ha a rendszer függőségi áb- 
rái irányított, körmentes gráfok, melyek megkönnyítik a rendszer megértését és tesztelését. 
Ennek elérése a felületeknél fontosabb (és könnyebb is), mint a megvalósításnál. 


Vegyük észre, hogy egy osztály három felületet írhat le: 


class X ( 
brivate: 

// csak tagok és barát függvények számára elérhető 
brotected: 

// csak tagok és "barátok", valamint 

// a származtatott osztály tagjai számára elérhető 
bublic: 

// általánosan elérhető 


J; 


Ezenkívül még a nyilvános felület részét képezik a , barátok" is (friend, §11.59. 
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A tagokat a legkorlátozottabb elérésű felület részeként célszerű megadni. Ez azt jelenti, 
hogy a tagok mindig privátok legyenek, hacsak nincs okunk arra, hogy hozzáférhetőbbé te- 
gyük azokat. Ha hozzáférhetőbbnek kell lenniük, legyenek védettek (protected), hacsak 
nincs okunk arra, hogy nyilvánosként (public) adjuk meg őket. Az adattagokat szinte soha 
nem szerencsés nyilvánossá vagy védetté tenni. A nyilvános felületet alkotó függvényeknek 
és osztályoknak az osztály olyan nézetét kell biztosítaniuk, amely illik ahhoz a szerephez, 
hogy az osztály egy fogalmat ábrázol. 


Az ábrázolás elrejtésének egy további szintjét absztrakt osztályok használatával biztosíthat- 


juk (42.5.4, §12.3, §25.3). 


24.4.3. Kövér felületek 


Ideális esetben egy felület csak olyan műveleteket kínálhat fel, melyeknek értelmük van és 
a felületet megvalósító bármely származtatott osztály által megfelelően leírhatók. Ez azon- 
ban nem mindig könnyű. Vegyük a listákat, tömböket, asszociatív tömböket, fákat stb. Mint 
ahogy a §16.2.2 pontban rámutattunk, csábító és néha hasznos ezeket a típusokat általáno- 
sítani — rendszerint egy tároló (konténer) használatával, melyet mindegyikük felületeként 
használhatunk. Ez (látszólag) felmenti a felhasználót a tároló részleteinek kezelése alól. Egy 
általános tárolóosztály felületének kialakítása azonban nem könnyű feladat. Tegyük fel, 
hogy a Container-t absztrakt típusként akarjuk meghatározni. Milyen műveleteket biztosít- 
son a Container? Megadhatnánk csak azokat a műveleteket, melyeket minden tároló képes 
támogatni — a művelethalmazok metszetét —, de ez nevetségesen szűk felület. Sok esetben 
a metszet valójában üres. A másik mód, ha az összes művelethalmaz unióját adjuk meg, fu- 
táskor pedig hibajelzést adunk, ha ezen a felületen keresztül valamelyik objektumra egy 
, nem létező" művelet alkalmazása történik. Az olyan felületet, mely egy fogalomhalmaz fe- 
lületeinek uniója, kövér felületnek (fat interface) nevezzük. Vegyünk egy Ttípusú objektu- 
mokat tartalmazó , általános tárolót": 


class Container f 


bublic: 
struct Bad oper ( // kivételosztály 
const char? p; 
Bad oper(const char"? pp) : P(pp) ( ? 
J; 


virtual void putconst T") f throw Bad oper("Container::but"); ) 
virtual T" getO ( throw Bad oper("Container::get"); ) 
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virtual T"k operatorl[[(int) f throw Bad operC"Container::[/Cint) "9; ? 
virtual T"k operatorlí[(const char") ( throw Bad oper( Container::[[(char")"; ) 
IL stee 


J; 


A Container-eket ezután így vezethetjük be: 


class List container : public Container, private list f 
bublic: 

void put(const T"; 

T" getO; 

// ... nincs operatonl/ ... 
2. 


J; 
class Vector. container : public Container, private vector ( 
bublic: 

T"£ operatorí[(int); 

Tk operatorlx(const char"); 

// ... nincs putO vagy getŐ ... 
2. 


6 
Amíg óvatosak vagyunk, minden rendben van: 


void JO 

t 
List container Sc; 
Vector. container vc; 
I vk 
WSer( sc, VC); 


j 


void user(Containerkg c1, Containerg c2) 


( 
T"p1 - c1.getO; 
T" p2 - c2l3]: 
// ne használjuk c2.getŐ vagy c1[3] műveletet 
Tas 


j 


Kevés azonban az olyan adatszerkezet, mely mind az indexeléses, mind a lista stílusú mű- 
veleteket jól támogatja. Következésképpen valószínűleg nem jó ötlet olyan felületet megha- 
tározni, mely mindkettőt megköveteli. Ha ezt tesszük, a hibák elkerülése érdekében futási 
idejű típuslekérdezést (415.4) vagy kivételkezelést (14. fejezet) kell alkalmaznunk: 
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void userXContainerk c1, Containerkg c2) // észlelni könnyű, de a helyreállítás nehéz 


lehet 
( 
try f 
T"p1 - c1.getO; 
Tt p2 - c203]; 
ga 
) 
catch(Container::Bad operk bad) f 
// Hoppá! 
// Most mit tegyünk? 
) 
j 


vagy 


void user3(Containerg c1, Containerdz c2) 
// a korai észlelés fárasztó, de a helyreállítás még mindig nehéz 
í 
if (dynamic cast£lList container"(kc1) kk dynamic cast Vector. container"(kc2)) f 
T"p1 - c1.getO; 


Tt p2 - c203]; 

VARTA 
) 
else ( 

// Hoppá! 

// Most mit tegyünk? 
) 


A futási idejű teljesítmény mindkét esetben csökkenhet és a létrehozott kód meglepően 
nagy lehet. Ez azt eredményezi, hogy a programozók hajlamosak figyelmen kívül hagyni 
a lehetséges hibákat, remélve, hogy valójában nem is fordulnak elő, amikor a program a fel- 
használók kezébe kerül. E megközelítéssel az a probléma, hogy a kimerítő tesztelés szintén 
nehéz és drága munka. 


Következésképpen a kövér felületeket a legjobb elkerülni ott, ahol a futási idejű teljesít- 
mény elsőrendűen fontos, ahol megköveteljük a kód helyességére vonatkozó garanciát, és 
általában ott, ahol van más jó megoldás. A kövér felületek használata gyengíti a megfelelte- 
tést a fogalmak és osztályok között és így szabad utat enged annak, hogy a származtatást 
pusztán a kényelmesebb megvalósítás kedvéért használjuk. 
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24.5. Tanácsok 


[1] 


[2] 
[3] 
[4] 


[5] 
[6] 


[7] 
[8] 
[9] 
[10] 


[11] 
[12] 


[13] 
[14] 
[15] 


[16] 


[17] 
[18] 


[19] 
[20] 
[21] 
[22] 
[23] 


[24] 


Törekedjünk az absztrakt adatábrázolásra és az objektumorientált programozásra. 
§24.2. 

A C45 tulajdonságait és technikáit (csak) szükség szerint használjuk. §24.2. 
Teremtsünk összhangot a tervezés és programozás stílusa között. §24.2.1. 

A függvények és a feldolgozás helyett a tervezésben elsődlegesen az osztályokra és 
fogalmakra összpontosítsunk. §424.2.1. 

A fogalmak ábrázolására használjunk osztályokat. §424.2.1, §24.3. 

A fogalmak közötti hierarchikus kapcsolatokat (és csak azokat) örökléssel ábrázol- 
juk. §24.2.2, §24.2.5, §24.3.2. 

A felületekre vonatkozó garanciákat fejezzük ki alkalmazásszintű statikus típusok- 
kal. §24.2.3. 

A pontosan meghatározható feladatok elvégzésének megkönnyítésére használjunk 
programgenerátorokat és közvetlen kezelőeszközöket. §24.2.4. 

Kerüljük az olyan programgenerátorokat és közvetlen kezelőeszközöket, melyek 
nem illeszkednek pontosan az adott általános célú programozási nyelvhez. 424.2.4. 
Az elhatárolható fogalmi szinteket válasszuk el. §24.3.1. 

Összpontosítsunk a komponensek tervezésére. §24.4. 

Mindig győződjünk meg róla, hogy egy adott virtuális függvénynek pontosan 
definiált jelentése van-e és hogy az azt felülbíráló minden függvény a kívánt visel- 
kedés egy változatát írja-e le. §24.3.5, §24.3.2.1. 

Használjunk nyilvános öröklést az is-a kapcsolatok ábrázolására. 424.3.4. 
Használjunk tagságot a has-a kapcsolatok ábrázolására. §24.3.4. 

Önállóan létrehozott objektumra hivatkozó mutatók helyett használjunk inkább 
közvetlen tagságot az egyszerű tartalmazási kapcsolatok kifejezésére. §24.3.3, 
§24.3.4. 

A uses függések legyenek világosak, (ahol lehetséges) kölcsönös függéstől mente- 
sek, és minél kevesebb legyen belőlük. §424.3.5. 

Minden osztályhoz adjunk meg invariánsokat. §24.3.7.1. 

Az előfeltételeket, utófeltételeket és más állításokat feltételezésekkel (lehetőleg az 
AssertO használatával) fejezzük ki. §24.3.7.2. 

A felületek csak a feltétlenül szükséges információkat tegyék elérhetővé. §24.4. 
Csökkentsük a felületek függéseit más felületektől. §24.4.2. 

A felületek legyenek erősen típusosak. §24.4.2. 

A felületeket alkalmazásszintű típusokkal fejezzük ki. §24.4.2. 

A felületek tegyék lehetővé, hogy a kérések átvihetők legyenek egy távoli 
kiszolgálóra. §424.4.2. 

Kerüljük a kövér felületeket. §24.4.3. 
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[25] Használjunk private adatokat és tagfüggvényeket, ahol csak lehetséges. §24.4.2. 

[26] A tervezők, illetve az általános felhasználók által igényelt származtatott osztályok 
elkülönítésére használjuk a public/protected megkülönböztetést. §24.4.2. 

[27] Az általánosított programozás érdekében használjunk sablonokat. §24.4.1. 

[28] Az algoritmusok eljárásmódot megadó paraméterezésére szintén sablonokat hasz- 
náljunk. §24.4.1. 

[29] Ha fordítási idejű típusfeloldásra van szükség, használjunk sablonokat. §24.4.1. 

[30] Ha futási idejű típusfeloldásra van szükség, használjunk osztályhierarchiákat. 
§24.4.1. 
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Az osztályok szerepe 


Vannak dolgok, melyek jobb, ha változnak... 
de az alapvető témáknak állandónak kell maradniuk. 
(Stephen J. Gould) 


Az osztályok fajtái " Konkrét típusok e Absztrakt típusok 9 Csomópontok se Változó felü- 
letek 9 Objektum [I/O s Műveletek e Felületosztályok s Leírók e Használatszámlálás e 
Keretrendszerek e Tanácsok s Gyakorlatok 


25.1. Az osztályok fajtái 


A C44 osztály egy programozási nyelvi szerkezet, többféle tervezési igény kiszolgálására. 
A bonyolultabb tervezési problémák megoldása általában új osztályok bevezetésével jár 
(esetleg más osztályok elhagyásával. Az új osztályokkal olyan fogalmakat ábrázolunk, 
amelyeket az előző tervvázlatban még nem határoztunk meg pontosan. Az osztályok sok- 
féle szerepet játszhatnak, ebből pedig az adódik, hogy a konkrét igényekhez egyedi osz- 
tályfajtákra lehet szükségünk. E fejezetben leírunk néhány alapvető osztálytípust, azok ere- 
dendő erősségeivel és gyengéivel együtt: 
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425.2 Konkrét típusok 
425.2 Absztrakt típusok 
425.4 Csomópontok 
§25.5 Műveletek 

§25.6 Felületek 

425.7 Leírók 

425.8 Keretrendszerek 


Ezek az , osztályfajták" tervezési fogalmak, nem nyelvi szerkezetek. A valószínűleg elérhe- 
tetlen ideál az lenne, ha rendelkezésre állna egyszerű és önálló osztályfajták egy olyan leg- 
kisebb halmaza, melyből az összes megfelelően viselkedő és használható osztályt megal- 
kothatnánk. Fontos, hogy észrevegyük: a fenti osztályfajták mindegyikének helye van 
a tervezésben és egyik sem eredendően jobb minden használatra a többinél. A tervezési és 
programozási viták során számos félreértés adódhat abból, hogy vannak, akik kizárólag egy 
vagy két fajta osztályt próbálnak használni. Ez rendszerint az egyszerűség nevében történik, 
de a ,kedvenc" osztályfajták torz és természetellenes használatához vezet. 


Jelen leírás ezeknek az osztályfajtáknak a ,tiszta" alakjaival foglalkozik, de természetesen 
kevert formák is használhatók. A keverékek azonban tervezési döntések eredményeként 
kell, hogy szülessenek, a lehetséges megoldások kiértékelésével, nem pedig a döntéshoza- 
talt elkerülve, céltalan kísérletezéssel. A , döntések elhalasztása" sokszor valójában a , gon- 
dolkodás elkerülését" jelenti. A kezdő tervezők rendszerint jól teszik, ha óvakodnak a ke- 
vert megoldásoktól és egy létező összetevő stílusát követik, melynek tulajdonságai az új 
komponens kívánt tulajdonságaira emlékeztetnek. Csak tapasztalt programozók kíséreljék 
meg egy általános célú komponens vagy könyvtár megírását, és minden könyvtártervezőt 
arra kellene , ítélni", hogy néhány évig a saját alkotását használja, dokumentálja és támogas- 
sa. (Lásd még: §23.5.1.) 


25.2. Konkrét típusok 


Az olyan osztályok, mint a vector (§16.3), a list (§17.2.29, a Date (§10.3) és a complex (§11.3, 
422.5) konkrétak abban az értelemben, hogy mindegyikük egy-egy viszonylag egyszerű fo- 
galmat ábrázol, az összes, e fogalom támogatásához nélkülözhetetlen művelettel együtt. 
Mindegyiküknél fennáll az ,egy az egyhez" megfelelés a felület és a megvalósítás között és 
egyiket sem szánták bázisosztálynak származtatáshoz. A konkrét típusok általában nem il- 
lenek bele egymással kapcsolatos osztályok hierarchiájába. Minden konkrét osztály önma- 
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gában megérthető, a lehető legkevesebb hivatkozással más osztályokra. Ha egy konkrét tí- 
pust megfelelően írunk le, az azt használó programok méretben és sebességben összemér- 
hetők lesznek azokkal a programokkal, melyekben a programozó egyénileg dolgozza ki 
a fogalom ábrázolását, majd annak egyedi célú (származtatott) változataival dolgozik. Ezen- 
kívül, ha a megvalósítás jelentősen változik, rendszerint a felület is módosul, hogy tükröz- 
Ze a változást. A konkrét típusok mindezekben a beépített típusokra emlékeztetnek. A be- 
épített típusok természetesen mind konkrétak. A felhasználói konkrét típusok, mint 
a komplex számok, mátrixok, hibaüzenetek és szimbolikus hivatkozások, gyakran az egyes 
alkalmazási területek alaptípusaiként használtak. 


Az adott osztály felületének természete határozza meg, mi minősül jelentős változtatásnak 
a megvalósításban; az elvontabb felületek ezen változtatásoknak több teret hagynak, de 
ronthatják a futási idejű hatékonyságot. Ezenkívül egy jó megvalósítás nem függ más osztá- 
lyoktól a feltétlenül szükségesnél erősebben, így az osztály a programban lévő , hasonló" 
osztályokhoz való alkalmazkodás szükségességének elkerülésével fordítási vagy futási ide- 
jű túlterhelés nélkül használható. 


Összegezve, egy konkrét típust leíró osztály céljai a következők: 


1. Szoros illeszkedés egy konkrét fogalomhoz és a megvalósítás módjához. 

2. Az ,egyénileg kidolgozott" kódéhoz mérhető gyorsaság és kis méret, a helyben 
kifejtés, valamint a fogalom és megvalósítása összes előnyét kihasználó művele- 
tek használatával. 

3. A más osztályoktól való lehető legkisebb arányú függés. 

4. Érthetőség és önálló használhatóság. 


Az eredmény a felhasználói és a megvalósító kód közti szoros kötés. Ha a megvalósítás bár- 
milyen módon megváltozik, a felhasználói kódot újra kell fordítani, mivel a felhasználói 
kód szinte mindig tartalmaz helyben kifejtett (inline) függvényhívásokat vagy a konkrét tí- 
pushoz tartozó helyi (lokális) változókat. 


A ,konkrét típus" elnevezést az általánosan használt , absztrakt típus" elnevezés ellentéte- 
ként választottuk. A konkrét és absztrakt típusok közti viszonyt a 425.3 pont tárgyalja. 


A konkrét típusok nem tudnak közvetlenül közösséget kifejezni. A list és a vector művelet- 
halmaza például hasonló és néhány sablon függvényben egymást helyettesíthetik. 
A listzint: és a vectorcsint?, vagy a listcShape?: és a listcCircle": között azonban nincs ro- 
konság (413.6.3), jóllehet mi észrevesszük a hasonlóságokat. 
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Ez azt is jelenti, hogy az egyes konkrét típusokat hasonló módon használó kódok külsejük- 
ben különbözők lesznek. Egy List bejárása a next művelettel például jelentősen különbö- 
zik egy Vector indexeléssel történő bejárásától: 


void my(distk s) 


Jor(T" p — sl.firstO; p; p — sl.nextO) ( // "természetes" lista-bejárás 
// egyik kód 

j 

12 etet 


j 


void you(Vectorg v) 


( 
for Gnt i — O; iZv.sizeO; it1) ( // "természetes" vektor-bejárás 
// másik kód 
) 
HALT 


j 


A bejárás stílusbeli különbsége természetes, abban az értelemben, hogy a , vedd a követke- 
ző elemet" művelet nélkülözhetetlen a lista fogalmánál, de nem ilyen magától értetődő egy 
vektornál, illetve hogy az indexelés nélkülözhetetlen a vektor fogalmánál, de a listánál nem 
az. Az, hogy a választott megvalósítási módhoz a , természetes" műveletek rendelkezésre 
álljanak, általában létfontosságú, mind a hatékonyság szempontjából, mind azért, hogy 
a kód könnyen megírható legyen. 


Magától értetődő nehézség, hogy az alapvetően hasonló műveletekhez (például az előbbi 
két ciklushoz) írott kód eltérően nézhet ki, a hasonló műveletekhez különböző konkrét tí- 
pusokat használó kódok pedig nem cserélhetők fel. Valós programoknál fejtörést igényel, 
hogy megtaláljuk a hasonlóságokat, és jelentős újratervezést, hogy a megtalált hasonlósá- 
gok kihasználására módot adjunk. A szabványos tárolók és algoritmusok is így teszik lehe- 
tővé a konkrét típusok hasonlóságainak kihasználását, hatékonyságuk és , eleganciájuk" el- 
vesztése nélkül (§16.2). 


Egy függvénynek ahhoz, hogy paraméterként elfogadjon egy konkrét típust, pontosan az 
adott típust kell megadnia paramétertípusként. Nem állnak rendelkezésre öröklési kapcso- 
latok, melyeket arra használhatnánk, hogy a paraméterek deklarálását általánosabbá te- 
gyük. Következésképpen a konkrét típusok közti hasonlóságok kihasználására tett kísérlet 
magával vonja a sablonok használatát és az általánosított (generikus) programozást, amint 
arról a §3.8 pontban már említést tettünk. Ha a standard könyvtárat használjuk, a bejárás így 
fog kinézni: 
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templatexclass C- void ours(const C£ c) 


Jor (C::const iterator p — c.beginO; p!/-c.endO; 414p) ( / standard könyvtárbeli bejárás 
VE 
, 
J 


Itt kihasználtuk a tárolók alapvető hasonlóságát, és ezzel megnyitottuk az utat a további ha- 
sonlóságok kihasználása felé, ahogyan azt a szabványos algoritmusok is teszik (18. fejezet). 


A felhasználónak a konkrét típus megfelelő használatához meg kell értenie annak pontos 
részleteit. (Általában) nem léteznek olyan általános tulajdonságok, melyek egy könyvtárban 
az összes konkrét típusra érvényesek lennének, és amelyekre támaszkodva a felhasználó- 
nak nem kell az egyes osztályok ismeretével törődnie. Ez az ára a futási idejű tömörségnek 
és hatékonyságnak. Néha megéri, néha nem. Olyan eset is előfordul, hogy könnyebb meg- 
érteni és használni egy konkrét osztályt, mint egy általánosabb (absztrakD) osztályt. A jól is- 
mert adattípusokat (pl. tömböket, listákat) ábrázoló osztályoknál gyakran ez a helyzet. 


Vegyük észre azonban, hogy az ideális továbbra is az, ha a megvalósításból a lehető legna- 
gyobb részt elrejtjük, anélkül, hogy a teljesítményt komolyabban rontanánk. A helyben ki- 
fejtett függvények ebben a környezetben nagy nyereséget jelenthetnek. Szinte soha nem jó 
ötlet, ha a tag változókat nyilvánossá tesszük vagy set és get függvényekről gondoskodunk, 
melyekkel a felhasználó közvetlenül kezelheti azokat (424.4.2). A konkrét típusok maradja- 
nak meg típusoknak, és ne , bitcsomagok" legyenek, melyeket a kényelem kedvéért néhány 
függvénnyel látunk el. 


25.2.1. A konkrét típusok újrahasznosítása 


A konkrét típusok ritkán használhatók alaptípusként további származtatáshoz. Minden 
konkrét típus célja egyetlen fogalom világos és hatékony ábrázolása. Az olyan osztály, mely 
ezt a követelményt jól teljesíti, ritkán alkalmas különböző, de egymással rokon osztályok 
nyilvános származtatás általi létrehozására. Az ilyen osztályok gyakrabban tehetők tagokká 
vagy privát bázisosztályokká, mert így anélkül használhatók hatékonyan, hogy felületüket 
és megvalósításukat keverni és rontani kellene új osztályokéval. Vegyük egy új osztály szár- 
maztatását a Date-ből: 


class My date : public Date f 
Ms 
j; 
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Szabályos-e a My date-et úgy használni, mint az egyszerű Date-et? Nos, ez attól függ, mi 
a My date, de tapasztalatom szerint ritkán lehet olyan konkrét típust találni, mely módosí- 


tás nélkül megfelel bázisosztálynak. 


A konkrét típusok ugyanúgy módosítás nélkül újrahasznosíthatók, mint az int-hez hasonló 
beépített típusok (§10.3.4): 


class Date and time f 
brivate: 

Date d; 

Time t; 
bublic: 

ZEN 


J; 


A felhasználásnak (újrahasznosításnak) ez a módja rendszerint egyszerű és hatékony. 


Lehet, hogy hiba volt a Date-et nem úgy tervezni, hogy származtatással könnyen lehessen 
módosítani? Néha azt mondják, minden osztálynak módosíthatónak kell lennie felülírás és 
származtatott osztályok tagfüggvényeiből való hozzáférés által. Ezt a szemléletet követve 
a Date-ből az alábbi változatot készíthetjük el: 


class Date2 ( 
bublic: 
// nyilvános felület, elsősorban virtuális függvényekből áll 
brotected: 
// egyéb megvalósítási részletek (esetleg némi ábrázolást is tartalmaz) 
brivate: 
// adatábrázolás és egyéb megvalósítási részletek 
2 


Jo 
A felülíró függvények hatékony megírását megkönnyítendő, az ábrázolást protected-ként 
deklaráltuk. Ezzel elértük célunkat: a Date2-t származtatással tetszőlegesen , hajlíthatóvá" 
tettük, változatlanul hagyva felhasználói felületét. Ennek azonban ára van: 


1. Kevésbé hatékony alapműveletek. A Ct- virtuális függvényeinek meghívása kis- 
sé lassabb, mint a szokásos függvényhívások; a virtuális függvények nem fordít- 
hatók helyben kifejtve olyan gyakran, mint a nem virtuális függvények; ráadásul 
a virtuális függvényekkel rendelkező osztályok egy gépi szóval több helyet igé- 
nyelnek. 

2. A szabad tár használatának szükségessége. A Date2 célja, hogy a belőle szár- 
maztatott osztályok objektumai felcserélhetőek legyenek. Mivel e származtatott 
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osztályok mérete különböző, kézenfekvő, hogy a szabad tárban foglaljunk szá- 
mukra helyet és mutatókkal vagy referenciákkal férjünk hozzájuk. A valódi 
lokális változók használata tehát drámaian csökken. 

3. Kényelmetlenség a felhasználónak. A virtuális függvények többalakúságát (poli- 
morfizmus) kihasználandó, a Date2-khöz mutatók vagy referenciák által kell 
hozzáférnünk. 

4. Gyengébb betokozás. A virtuális műveletek felülírhatók és a védett adatok 
a származtatott osztályokból módosíthatók (§12.4.1.1. 


Természetesen ezek a , költségek" nem mindig jelentősek és az így létrehozott osztály gyak- 
ran pontosan úgy viselkedik, mint ahogy szerettük volna (425.3, §25.4). Egy egyszerű konk- 
rét típusnál (mint a Date2) azonban ezek nagy és szükségtelen költségek. 


A , hajlíthatóbb" típus ideális ábrázolására sokszor egy jól megtervezett konkrét típus a leg- 
alkalmasabb: 


class Date3 ( 
public: 
// nyilvános felület, elsősorban virtuális függvényekből áll 
Private: 
Date d; 
J; 


Így a konkrét típusok (a beépített típusokat is beleértve) osztályhierarchiába is illeszthetők, 
ha szükséges. (Lásd még §425.10[1].) 


25.3. Absztrakt típusok 


Az osztályokat, valamint az objektumokat létrehozó és az azokat felhasználó kód közötti 
kötelék lazításának legegyszerűbb módja egy absztrakt osztály bevezetése, mely a fogalom 
különböző megvalósításainak halmazához közös felületet biztosít. Vegyünk egy természe- 
tes Set-et (halmazo: 


templatexclass T- class Set ( 
bublic: 
virtual void insert(T?) — 0; 
virtual void remove( IT?) — 0; 
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virtual int is member(T?) - 0; 


virtual T" firstŐ - 0; 
virtual T" nextŐ — 0; 


virtual -Set0 [ ) 


J; 


Ez meghatározza a halmaz felületét és tartalmazza az elemek bejárásának módját is. 
A konstruktor hiánya és a virtuális destruktor jelenléte szokványos (412.4.2). Többféle meg- 
valósítás lehetséges (§16.2.19: 


templatexclass T- class List set : public SetZT:, private listzT: f 
Mosó 


J; 


templatexciass T- class Vector. set : public SetZT:, private vectorzT: ( 
xset 


J; 


Az egyes megvalósításokhoz az absztrakt osztály adja a közös felületet, vagyis a Set-tel anél- 
kül dolgozhatunk, hogy tudnánk, melyik megvalósítását használjuk: 


void (SetcPlanet:£ 5) 


( 
for (Plane? p - s firstO; p; p - s.nextO) ( 
// saját kód 
j 
Ta 


) 
List setkPlane": sl; 
Vector. setkPlanet: (1009; 


void gO 
( 
HSD; 
HV; 
2 


J 


A konkrét típusoknál megköveteltük a megvalósító osztályok újratervezését, hogy kifejez- 
zék a közösséget, annak kiaknázására pedig sablont használtunk. Itt a közös felületet kell 
megterveznünk (esetünkben a Set-et), de semmi más közöset nem kívánunk a megvalósí- 
tásra használt osztályoktól, mint azt, hogy meg tudják valósítani a felületet. 


25. Az osztályok szerepe 1039 


Továbbá, a Set-et felhasználó programelemeknek nem kell ismerniük a List set és 
a Vector. set deklarációit, tehát nem kell függniük ezektől. Ezenkívül nem kell sem újrafordí- 
tanunk, sem bármilyen más változtatást végeznünk, ha a List set vagy a Vector. set megvál- 
tozik, vagy ha bevezetjük a Setegy újabb megvalósítását, mondjuk a 7ree set-et. Minden füg- 
gést a függvények tartalmaznak, melyek a Set-ből származtatott osztályokat használják. 
Vagyis — feltételezve, hogy a szokásos módon használjuk a fejállományokat — az ((Setk ) 
megírásakor csak a Set.h-t kell beépítenünk (sincludo), a List set.h-t vagy a Vector. set.h-t 
nem. Csak ott van szükség egy , implementációs fejállományra", ahol egy List set, illetve egy 
Vector. set létrehozása történik. Az egyes megvalósítások további elszigetelését jelentheti 
a tényleges osztályoktól, ha egy absztrakt osztályt vezetünk be, mely az objektum-létrehozá- 
si kéréseket kezeli ( gyár", factory, §12.4.4). 


A felületnek ez az elválasztása a megvalósítástól azzal a következménnyel jár, hogy , eltű- 
nik" a hozzáférés azon műveletekhez, melyek , természetesek" egy adott megvalósítás szá- 
mára, de nem elég általánosak ahhoz, hogy a felület részei legyenek. Például, mivel a Set 
nem rendelkezik a rendezés képességével, a Set felületében nem támogathatunk egy index- 
kezelő operátort még akkor sem, ha történetesen egy tömböt használó Set-et hozunk létre. 
A ,kézi" optimalizálás hiánya miatt ez növeli a futási időt, ezenkívül általában nem élhetünk 
a helyben kifejtés előnyeivel sem (kivéve azokat az egyedi eseteket, amikor a fordító isme- 
ri a valódi típust), és a felület minden lényeges művelete virtuális függvényhívás lesz. Mint 
a konkrét típusok, az absztrakt típusok használata is néha megéri; néha nem. Összefoglal- 
va, az absztrakt típusok céljai a következők: 


1. Egy egyszerű fogalom oly módon való leírása, mely lehetővé teszi, hogy a prog- 
ramban a fogalomnak több megvalósítása is létezhessen. 

2. Elfogadható futási idő és takarékos helyfoglalás biztosítása virtuális függvények 
használatával. 

3. Az egyes megvalósítások lehető legkisebb függése más osztályoktól. 

4. Legyen érthető önmagában. 


Az absztrakt típusok nem jobbak, mint a konkrét típusok, csak másmilyenek. A felhaszná- 
lónak kell döntenie, melyiket használja. A könyvtár készítője elkerülheti a kérdést azáltal, 
hogy mind a kettőt biztosítja, a felhasználóra hagyva a választást. Az a fontos, hogy világos 
legyen, az adott osztály melyik típusba tartozik. Ha korlátozzuk egy absztrakt típus általá- 
nosságát, hogy sebességben állja a versenyt egy konkrét típussal, rendszerint kudarcot val- 
lunk. Ez ugyanis veszélyezteti azt a képességét, hogy egyes megvalósításait egymással he- 
lyettesíthessük, a változtatás utáni újrafordítás szükségessége nélkül. Hasonlóképpen 
rendszerint kudarccal jár, ha konkrét típusokat , általánosabbá" akarunk tenni, hogy az 
absztrakt típusok tulajdonságaival összemérhetők legyenek, mert így veszélybe kerül az 
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egyszerű osztály hatékonysága és pontossága. A két elképzelés együtt létezhet — valójában 
együtt kell hogy létezzen, mivel az absztrakt típusok megvalósítását konkrét típusok ad- 
ják —, de nem szabad őket összekeverni egymással. 


Az absztrakt típusok gyakran közvetlen megvalósításukon túl nem szolgálnak további szár- 
maztatások alapjául. Új felület azonban felépíthető egy absztrakt osztályból, ha belőle egy 
még tágabb absztrakt osztályt származtatunk. Ezt az új absztrakt osztályt kell majd további 
származtatáson keresztül megvalósítani egy nem absztrakt osztállyal (415.2.59. 


Miért nem származtattunk a Set-ből egy lépésben List és Vector osztályokat, elhagyva 
a List setés Vector. set osztályok bevezetését? Más szóval, miért legyenek konkrét típusaink, 
ha absztrakt típusaink is lehetnek? 


1. Hatékonyság. Azt akarjuk, hogy konkrét típusaink legyenek (mint a vector és 
a lisD, azon túlterhelés nélkül, amit a megvalósításnak a felülettől való elválasz- 
tása okoz (az absztrakt típusoknál ez történik). 

2. Újrahasznosítás. Szükségünk van egy módra, hogy a ,máshol" tervezett típuso- 
kat (mint a vector és a lisD beilleszthessük egy új könyvtárba vagy alkalmazás- 
ba, azáltal, hogy új felületet adunk nekik (nem pedig újraírjuk őkeD. 

3. Több felület. Ha egyetlen közös alapot használunk többféle osztályhoz, az kövér 
felületekhez vezet (§24.4.39. Gyakran jobb, ha az új célra használni kívánt osz- 
tálynak új felületet adunk (mint egy vector-nak egy Set felülete), ahelyett, hogy 
a több célra való használhatóság kedvéért az eredeti felületet módosítanánk. 


Természetesen ezek egymással összefüggő kérdések. Az /val box példában (412.4.2, 
§15.2.5) és a tárolók tervezésével kapcsolatban (§16.2) részletesebben tárgyaltuk ezeket. Ha 
a Set bázisosztályt használtuk volna, az egy csomópont-osztályokon nyugvó alaptárolót 
eredményezett volna (425.4). 


A §25.7 pont egy rugalmasabb bejárót (iterátort) ír le, ahol a bejáró a kezdeti értékadásnál 
köthető az objektumokat biztosító megvalósításhoz és ez a kötés futási időben módosítható. 
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25.4. Csomópont-osztályok 


Az osztályhierarchiák más származtatási szemlélet alapján épülnek fel, mint az absztrakt 
osztályoknál használt, felületből és megvalósításból álló rendszer. Itt az osztályokat alapnak 
tekintjük, melyre más osztályokat építünk. Még ha absztrakt osztály is, rendszerint van va- 
lamilyen ábrázolása és ad valamilyen szolgáltatásokat a belőle származtatott osztályoknak. 
Ilyen csomópont-osztályok például a Polygon (412.3), a (kiinduló) /val slider (§12.4.1) és 
a Satellite (§15.2). 


A hierarchián belüli osztályok jellemzően egy általános fogalmat ábrázolnak, míg a belőlük 
származtatott osztályok úgy tekinthetők, mint az adott fogalom konkretizált (egyedi célú, 
, szakosított") változatai. Az egy hierarchia szerves részeként tervezett osztályok — a csomó- 
bont-osztályok (node class) — a bázisosztály szolgáltatásaira támaszkodva biztosítják saját 
szolgáltatásaikat, vagyis a bázisosztály tagfüggvényeit hívják meg. A csomópont-osztályok 
általában nem csupán a bázisosztályuk által meghatározott felület egy megvalósítását adják 
(mint egy absztrakt típusnak egy megvalósító osztály), hanem maguk is hozzátesznek új 
függvényeket, ezáltal szélesebb felületet biztosítanak. Vegyük a §24.3.2 forgalomszimu- 
lációs példájában szereplő Car-t: 


class Car : public Vehicle f 
bublic: 
Car(int passengers, Size category size, int weight, int fc) 
: Vehicle(passengers, size, weight), fuel capacity(fo €/? ... "/ ) 


// a Vehicle lényeges virtuális függvényeinek felülírása 


void tur(Direction); 


Mas 
// Car-ra vonatkozó függvények hozzáadása 


virtual void add fuel(int amount; // az autó üzemanyagot igényel 
I sza 
j; 


A fontos függvények: a konstruktor, mely által a programozó a szimuláció szempontjából 
lényeges alaptulajdonságokat határozza meg és azok a (virtuális) függvények, melyek a szi- 


mulációs eljárásoknak lehetővé teszik, hogy egy Car-t anélkül kezeljenek, hogy tudnák an- 
nak pontos típusát. Egy Car az alábbi módon hozható létre és használható: 
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void userO 


( 
Hl 
Car?" p - new Car( ő, economy, 1500,609; 
drive(p,bs home, MID; // belépés a szimulált forgalmi helyzetbe 
MZGEYB 


A csomópont-osztályoknak rendszerint szükségük van konstruktorokra és ez a konstruktor 
gyakran bonyolult. Ebben a csomópont-osztályok eltérnek az absztrakt osztályoktól, me- 
lyeknek ritkán van konstruktoruk. 


A Car műveleteinek megvalósításai általában a Vehicle bázisosztályból vett műveleteket 
használják, a Car-okat használó elemek pedig a bázisosztályok szolgáltatásaira támaszkod- 
nak. A Vehicle például megadja a súllyal és mérettel foglalkozó alapfüggvényeket, így 
a Car-nak nem kell gondoskodnia azokról: 


bool Bridge::can cross(const Vehiclek r) 


( 


if (max  weight-r.weightO) return false; 
sz 


j 
Ez lehetővé teszi a programozó számára, hogy új osztályokat (Car és Truck) hozzon létre 
a Vehicle csomópont-osztályból, úgy, hogy csak az attól különböző tulajdonságokat és mű- 
veleteket kell megadnia, illetve elkészítenie. Ezt az eljárást gyakran úgy említik, mint , kü- 
lönbség általi programozást" vagy , bővítő programozást". 


Sok csomópont-osztályhoz hasonlóan a Car maga is alkalmas a további származtatásra. 
Az Ambulance-nek például további adatokra és műveletekre van szüksége a vészhelyzetek 
kezeléséhez: 


class Ambulance : public Car, public Emergency f 
bublic: 
AmbulanceO; 


// a Car lényeges virtuális függvényeinek felülírása 


void turn(Direction); 


Még 


// az Emergency lényeges virtuális függvényeinek felülírása 
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virtual void dispatch to(const Location ); 
VA 


// Ambulance-ra vonatkozó függvények hozzáadása 


virtual int patient capacityO; // hordágyak száma 
ző 
j; 


Összegezzük a csomópont-osztályok jellemzőit: 


1. Mind megvalósítását, mind a felhasználóknak adott szolgáltatásokat tekintve 
bázisosztályaira támaszkodik. 

2. Szélesebb felületet (vagyis több nyilvános tagfüggvénnyel rendelkező felületet) 
ad felhasználóinak, mint bázisosztályai. 

3. Elsődlegesen (de nem feltétlenül kizárólagosan) a nyilvános felületében levő 

virtuális függvényekre támaszkodik. 

Függ az összes (közvetlen és közvetet) bázisosztályától. 

Csak bázisosztályaival összefüggésben érthető meg. 

További származtatás bázisosztályaként felhasználható. 

Objektumok létrehozására használható. 


S EKONISASZHÉS 


Nem minden csomópont-osztály fog eleget tenni az 1, 2, 6 és 7 mindegyikének, de a leg- 
több igen. A 6-nak eleget nem tevő osztályok a konkrét típusokra emlékeztetnek, így konk- 
rét csomópont-osztályoknak nevezhetők. A konkrét csomópont-osztályok például absztrakt 
osztályok megvalósításához használhatók (§12.4.2), az ilyen osztályok változói számára pe- 
dig statikusan és a veremben is foglalhatunk helyet. Az ilyen osztályokat néha levél osztá- 
lyoknak nevezzük. Ne feledjük azonban, hogy minden kód, amely egy osztályra hivatkozó 
mutatón vagy referencián virtuális függvények által végez műveletet, számításba kell, hogy 
vegye egy további osztály származtatásának lehetőségét (vagy nyelvi támogatás nélkül el 
kell fogadnia, hogy nem történt további származtatás). Azok az osztályok, melyek nem tesz- 
nek eleget a 7-es pontnak, az absztrakt típusokra emlékeztetnek, így absztrakt csomópont- 
osztályoknak hívhatók. A hagyományok miatt sajnos sok csomópont-osztálynak van leg- 
alább néhány protected tagja, hogy a származtatott osztályok számára kevésbé korlátozott 
felületről gondoskodjon (412.4.1.1. 


A 4-es pontból az következik, hogy a csomópont-osztályok fordításához a programozónak 
be kell építenie ($include) azok összes közvetlen és közvetett bázisosztály-deklarációit és 
az összes olyan deklarációt, melyektől azok függnek. Ez megint csak egy különbség a cso- 
mópont-osztályok és az absztrakt típusok között, az utóbbiakat használó programelemek 
ugyanis nem függnek a megvalósításukra használt osztályoktól, így nem kell azokat a for- 
dításhoz beépíteni. 
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25.4.1. Felületek módosítása 


Minden csomópont-osztály egy osztályhierarchia tagja, egy hierarchián belül viszont nem 
minden osztálynak kell ugyanazt a felületet nyújtania. Nevezetesen, egy származtatott osz- 
tály több tagfüggvénnyel rendelkezhet és egy testvérosztály függvényhalmaza is teljesen 
más lehet. A tervezés szempontjából a dynamic cast (§15.4) úgy tekinthető, mint az az el- 
járás, mellyel egy objektumot megkérdezhetünk, biztosít-e egy adott felületet. 


Példaként vegyünk egy egyszerű objektum [/O (bemeneti/kimeneti) rendszert. A felhasz- 
náló egy adatfolyamból objektumokat akar olvasni, meg kívánja határozni, hogy a várt tí- 
pusúak-e, majd fel akarja használni azokat: 


void userO 

( 
// ... feltételezés szerint alakzatokat (Shape) tartalmazó fájl megnyitása 
// ss által azonosított bemeneti adatfolyamként ... 


Io obj? p - get obj(s5); // objektum olvasása az adatfolyamról 


if (Shape? sp - dynamic castsShapetx(p)) ( 


sp-2drawO; // alakzat használata 
Ma 
J 
else ( 
// hoppá: ez nem alakzat 
) 


A userO függvény az alakzatokat kizárólag az absztrakt Shape osztályon keresztül kezeli és 
ezáltal minden fajta alakzatot képes használni. A dynamic cast használata lényeges, mert 
az objektum [/O rendszer számos objektumfajtát kezel, a felhasználó pedig véletlenül olyan 
fájlt is megnyithatott, amely olyan osztályok — egyébként tökéletesen jó — objektumait tar- 
talmazza, melyekről a felhasználó nem is hallott. 


A rendszer feltételezi, hogy minden olvasott vagy írt objektum olyan osztályhoz tartozik, 
amely az Jo objleszármazottja. Az Jo obj osztálynak többalakúnak (polimorfnak) kell len- 
nie, hogy lehetővé tegye számunkra a dynamic cast használatát: 


class Io obj(f 

bublic: 
virtual Io obj? cloneO const -0; // többalakú 
virtual -Io objO 1? 

2. 


76) 
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A rendszer létfontosságú eleme a get objO függvény, mely egy istream adatfolyamból ada- 
tokat olvas és osztályobjektumokat hoz létre azokra alapozva. Tegyük fel, hogy a bemene- 
ti adatftolyamban az egyik objektumot képviselő adatok előtagként egy, az objektum osztá- 
lyát azonosító karakterláncot tartalmaznak. A get objO függvény feladata ezt elolvasni, 
majd egy olyan függvényt meghívni, amely képes a megfelelő osztályú objektumot létre- 


hozni és kezdőértéket adni neki: 


tybedef Io obj? GCPFOGistreamk);  // Io obj" visszatérési típusú függvényre hivatkozó 
mutató 


mapsstring,PF- io map; // karakterláncok hozzárendelése a létrehozó függvényekhez 
bool get word(istreamdg is, string 5); // szó beolvasása is-ből s-be 


Io obj" get obj(istreamd 5) 

( 
string SÍT; 
bool b - get word(S,Str); // a kezdő szó beolvasása str-be 
if (b —— false) throw No. classO; // io formátumhiba 


PFf- io maplistri; // az "str" kikeresése, hogy kiválasszuk a függvényt 
if (f -— 0) throw Unknown classO; // nem találjuk "str"-t 


return 59; // objektum létrehozása az adatfolyamból 


J 


Az io map nevű map neveket tartalmazó karakterláncok és a nevekhez tartozó osztályok 
objektumait létrehozni képes függvények párjaiból áll. 


A Shape osztályt a szokásos módon határozhatjuk meg, azzal a kivétellel, hogy a userO ál- 
tal megkövetelten az Jo obj-ból származtatjuk: 


class Shape : public Io objf 
04 
j; 


Még érdekesebb Cés sok esetben valószerűbb) lenne azonban egy meghatározott Shape-et 
(42.6.2) módosítás nélkül felhasználni: 


class Io circle : public Circle, public Io objf 

bublic: 
Io circle? cloneO const f return new Io circleC:this); ) // másoló konstruktor használata 
Io circleCistreamé£ ); // kezdeti értékadás a bemeneti adatfolyamból 
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static Io obj?" new circle(istreamd s) f return new Io circle(59; ) 


Mata 


J; 


Ez annak példája, hogyan lehet egy osztályt egy absztrakt osztály használatával beilleszte- 
ni egy hierarchiába, ami kevesebb , előrelátást" igényel, mint amennyi ahhoz kellene, hogy 
először csomópont-osztályként hozzuk létre (§12.4.2, 425.3). 


Az Io. circle(istreamd ) konstruktor az objektumokat az iostream-ből kapott adatokkal töl- 
ti fel. A new circle0 függvényt az io map-ba tesszük, hogy az osztályt a bemeneti/kimene- 
ti rendszer számára ismertté tegyük: 


io mapfl" To. circle"J-k£Io circle::new circle; 


Más alakzatokat hasonló módon hozhatunk létre: 


class Io. triangle : public Triangle, public Io obj( 
sza 


J; 


Ha az objektum [/O rendszer elkészítése túl fáradságos, segíthet egy sablon: 


templatexclass T- class Io : public T, public Io objf 
bublic: 
Io" cloneO const f return new IoC"this); ) // felülbírálja Io obj::clone0-t 


Io(istreameé£ ); // kezdeti értékadás bemeneti adatfolyamból 


static Io? new io(istreamdg 5) f( return new Io(59; ) 


sss 


3; 


Ha a fenti adott, meghatározhatjuk az Jo circle-t: 


typedef IosCircle: Io circle; 


Természetesen továbbra is pontosan definiálnunk kell az JozCirclez:: IJo(istreamd J-et, mi- 
vel annak részleteiben ismernie kell a Circle-t. Az Jo sablon példa arra, hogyan illeszthetünk 
be konkrét típusokat egy osztályhierarchiába egy leíró (handle) segítségével, amely az adott 
hierarchia egy csomópontja. A sablon saját paraméteréből származtat, hogy lehetővé tegye 
az átalakítást az Jo obj-ról, de ez sajnos kizárja az Jo-nak beépített típusokra történő 


alkalmazását: 
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typedef IocDate: Io date; — // konkrét típus beburkolása 
typedef Iocint? Io int; // hiba: nem származtathatunk beépített típusból 


A probléma úgy kezelhető, ha a beépített típusok részére külön sablont biztosítunk vagy ha 
egy beépített típust képviselő osztályt használunk (§$25.10[1D. 


Ez az egyszerű objektum [/O rendszer nem teljesíthet minden kívánságot, de majdnem el- 
fér egyetlen lapon és fő eljárásait számos célra felhasználhatjuk, például meghívhatjuk ve- 
lük a felhasználó által karakterlánccal megadott függvényeket vagy ismeretlen típusú ob- 
jektumokat kezelhetünk futási idejű típusazonosítással felderített felületen keresztül. 


25.5. Műveletek 


A C44-ban a műveletek meghatározásának legegyszerűbb és legkézenfekvőbb módja függ- 
vények írása. Ha azonban egy adott műveletet végrehajtás előtt késleltetni kell, át kell vin- 
ni , máshová", párosítani kell más műveletekkel vagy a művelet saját adatokat igényel 
(§25.10 [18, 19], gyakran célszerűbb azt osztály alakjában megadni, mely végre tudja hajta- 
ni a kívánt eljárást és egyéb szolgáltatásokat is nyújthat. Jó példák erre a szabványos algo- 
ritmusok által használt függvény-objektumok (§18.4), valamint az iostream-mel használt 
módosítók (§21.4.69. Az előbbi esetben a tényleges műveletet a függvényhívó operátor hajt- 
ja végre, míg az utóbbinál a cc vagy a 22 operátor. A Form (§21.4.6.3) és a Matrix (§22.4.7) 
esetében a végrehajtás késleltetésére egyedi (compositor) osztályokat használunk, amíg 
a hatékony végrehajtáshoz elegendő információ össze nem gyűlik. 


A műveletosztályok általános formája egy (jellemzően valamilyen , csináld" (do it) nevű) 
virtuális függvényt tartalmazó egyszerű osztály: 


class Action ( 

bublic: 
virtual int do it(int) — O; 
virtual -ActionO f ; 


); 


Ha ez adott, olyan kódot írhatunk — mondjuk egy menüét — amely a műveleteket későbbi 
végrehajtásra , elraktározhatja", anélkül, hogy függvénymutatókat használna, bármit is tud- 
na a meghívott objektumokról vagy egyáltalán ismerné a meghívott művelet nevét: 
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class Write file : public Action f 
Filegz f; 
bublic: 
int do it(Gint) ( return f.writeO .succeedO); ) 
2; 
class Error. response : public Action f 
string message; 
bublic: 
int do it(inb); 


J; 


int Error. response::do. it(int) 


( 


Response box db(message.c strO, "Folytat", "Mégse", "Ismét"; 


switch (db.get resbonseO) f 


case O: 
return 0; 
case I: 
abortO; 
case 2: 
current operation.redoO); 
return 1; 
J 


J 


Action? actions[] — ( 
new Write file(f), 
new Error. response( Megint elrontotta"), 


Ass 


J; 


Az Action-t használó kód teljesen elszigetelhető, nem kell, hogy bármit is tudjon az olyan 
származtatott osztályokról, mint a Write file és az Error. response. 


Ez igen erőteljes módszer, mellyel óvatosan kell bánniuk azoknak, akik leginkább a funk- 
cionális elemekre bontásban szereztek tapasztalatot. Ha túl sok osztály kezd az Action-re 
hasonlítani, lehet, hogy a rendszer átfogó terve túlzottan műveletközpontúvá vált. 


Megemlítendő, hogy az osztályok jövőbeni használatra is tárolhatnak műveleteket, illetve 
olyanokat is tartalmazhatnak, melyeket egy távoli gép hajt majd végre (425.10 [18]. 
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25.6. Felületosztályok 


Az egyik legfontosabb osztályfajta a szerény és legtöbbször elhanyagolt felületosztály. Egy 
felületosztály nem sok dolgot csinál — ha csinálna, nem lenne felületosztály —, csupán helyi 
szükségletekhez igazítja egy szolgáltatás megjelenését. Mivel elvileg lehetetlen mindig, 
minden szükségletet egyformán jól kielégíteni, a felületosztályok nélkülözhetetlenek, mert 
anélkül teszik lehetővé a közös használatot, hogy minden felhasználót egyetlen, közös 
,kényszerzubbonyba" erőszakolnának. 


A felületek legtisztább formájukban még gépi kódot sem igényelnek. Vegyük a §13.5-ből 
a Vector specializált változatát: 


templatexclass T: class VectorST": : private Vectorgvoid": ( 
bublic: 
typedef Vectorgvoid?5 Base; 


VectorO : BaseO f? 
Vector(int i) : Base(i) () 


T"£k operatorí[Gint i) f return static casiZT:ko-(Base::operatort[ 9; ) 


VAA 


Ez a (részlegesen) specializált változat a nem biztonságos Vectorcvoid?:-ot egy sokkal 
használhatóbb, típusbiztos vektorosztály-családdá teszi. A helyben kifejtett (inline) függvé- 
nyek gyakran nélkülözhetetlenek ahhoz, hogy a felületosztályokat megengedhessük ma- 
gunknak. A fentihez hasonló esetekben, ahol a helyben kifejtett közvetítő függvény csak tí- 
pusigazítást végez, sem a futási idő, sem a tárigény nem nő. 


Természetesen az absztrakt típust ábrázoló absztrakt bázisosztályok, melyeket konkrét típu- 
sok (425.2) valósítanak meg, szintén a felületosztályok egy formáját jelentik, mint ahogy 
a 425.7 leírói is azok. Itt azonban azon osztályokra összpontosítunk, melyeknek a felület 
igazításán kívül nincs más feladatuk. 


Vegyük két, többszörös öröklést használó hierarchia összefésülésének problémáját. Mit le- 
het tenni, ha névütközés lép fel, vagyis két osztály ugyanazt a nevet használja teljesen elté- 
rő műveleteket végző virtuális függvényekhez? Vegyünk például egy vadnyugati videojáté- 
kot, melyben a felhasználói beavatkozásokat egy általános ablakosztály kezeli: 
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class Window f 
1 aa 


virtual void drawO; // kép megjelenítése 


J; 


class Cowboy f 
ÜSS 


virtual void drawO; // pisztoly előrántása a pisztolytáskából 


J; 


class Cowboy window : public Cowboy, public Window f 
Üsse; 


b 
A játékban a cowboy mozgatását egy Cowboy window képviseli és ez kezeli a felhasználó (já- 
tékos) és a cowboy figura közötti , kölcsönhatásokat" is. A Window és a Cowboy tagokként 
való bevezetése helyett többszörös öröklést szeretnénk használni, mivel számos kiszolgáló 
függvényt kell meghatároznunk mind a Window-k, mind a Cowboy-ok részére, 
a Cowboy window-kat pedig olyan függvényeknek szeretnénk átadni, melyek nem kívánnak 
a programozótól különleges munkát. Ez azonban ahhoz a problémához vezet, hogy meg kell 
adni a Cowboy::drawO és Window::drawO függvények Cowboy window változatát. 


A Cowboy window-ban csak egy drawO nevű függvény lehet. Ennek viszont — mivel 
a Window-kat és Cowboy-okat a Cowboy window-k ismerete nélkül kezeljük — felül kell 
írnia mind a Cowboy, mind a Window draw függvényét. Egyetlen változattal nem írhatjuk 
felül mind a kettőt, mert a közös név ellenére a két drawO függvény szerepe más. Végeze- 
tül azt is szeretnénk, hogy a Cowboy window egyedi, egyértelmű neveket biztosítson az 
örökölt Cowboy::drawO és Window:: drawO függvények számára. 


A probléma megoldásához szükségünk van egy-egy további osztályra a Cowboy-hoz és 
a Window-hoz. Ezek az osztályok vezetik be a két új nevet a drawO függvényekre és biz- 
tosítják, hogy a Cowboy-ban és a Window-ban a drawO függvényhívások az új néven hív- 
ják a függvényeket: 


class CCowboy : public Cowboy (f // felület a Cowboy-hoz: a drawO-t átnevezi 
bublic: 

virtual int cow drawO — 0; 

void drauO f cow drawO); ) // felülírja Cowboy::drawO-t 


J; 
class WWindow : public Window ( // felület a Window-hoz: a drawO-t átnevezi 
bublic: 

virtual int win drawO — 0; 

void drawO ( win drawO); ) // felülírja Window::drawO-t 


J; 
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Most már összerakhatunk egy Cowboy window-t a CCowboy és a WWindow felületosztá- 
lyokból és a kívánt hatással felülbírálhatjuk a cow drawO-t és win drawO-t: 


class Cowboy window : public CCowboy, public WWindow f 
Ms 
void cow drawO; 
void win drawO; 


5 


Vegyük észre, hogy a probléma csak amiatt volt komoly, hogy a két drawO függvénynek 
ugyanaz a paramétertípusa. Ha a paramétertípusok különböznek, a szokásos túlterhelés- 
feloldási szabályoknak köszönhetően nem lesz probléma, annak ellenére, hogy az egymás- 


sal kapcsolatban nem lévő függvényeknek ugyanaz a nevük. 

Egy felületosztály minden használatára elképzelhetünk egy különleges célú nyelvi bővítést, 
mely a kívánt igazítást hatékonyabban vagy elegánsabban tudná elvégezni. A felületosztá- 
lyok egyes használatai azonban ritkák, és ha mindet egyedi nyelvi szerkezettel támogatnánk, 
túlzottan bonyolulttá tennénk programjainkat. Az osztályhierarchiák összefésüléséből eredő 
névütközések nem általánosak (ahhoz képest, hogy milyen gyakran ír osztályt egy progra- 
mozó), inkább abból erednek, hogy eltérő környezetben létrehozott hierarchiákat olvasz- 
tunk össze (pl. játékokat és ablakrendszereke0. Az ilyen eltérő hierarchiákat nem könnyű 
összefésülni és a névütközések feloldása gyakran csak csepp a tengerben a programozó szá- 
mára. Problémát jelenthet az eltérő hibakezelés, kezdeti értékadás és tárkezelési mód is. 
A névütközések feloldását itt azért tárgyaljuk, mert a közvetítő/továbbító szerepet betöltő fe- 
lületosztályok bevezetése más területeken is alkalmazható; nem csak nevek megváltoztatá- 
sára, hanem paraméterek és visszatérési értékek típusának módosítására, futási idejű ellen- 
őrzés bevezetésére stb. is. Minthogy a CCowboy::drawO és WWindow::drawO függvények 
virtuálisak, nem optimalizálhatók egyszerű helyben kifejtéssel. Lehetséges viszont, hogy 
a fordító felismeri, hogy ezek egyszerű továbbító függvények, és a rajtuk átmenő hívási lán- 
cok alapján képes optimális kódot készíteni. 


25.6.1. Felületek igazítása 


A felületfüggvények egyik fő felhasználása egy felület igazítása úgy, hogy az jobban illesz- 
kedjék a felhasználó elvárásaihoz; vagyis egyetlen felületbe helyezzük azt a kódot, amely 
különben a felhasználói kódon belül szét lenne szórva. A szabványos vector például nulla 
alapú, azaz az első elem indexe 0. Azoknak a felhasználóknak, akik a O-tól size-1-ig terje- 


dő tartománytól eltérőt akarnak, igazítást kell végezniük: 
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void JO 
( 


vector vAint2(109; // (0:9] tartomány 
// úgy teszünk, mintha v a [1:10] tartományban lenne 


for (int i -— 1; i£—-10; ií43) f 
uli-1] — 7; // ne felejtsük az indexet igazítani 
VE 


Még jobb, ha a vector-nak tetszőleges határokat biztosítunk: 


class Vector : public vectorcint: ( 
int lb; 
bublic: 
Vector(int low, int high) : vectorzint:(high-lowx 1) ( Ib-low; ) 


intk operatorl[[(int i) f return vectorsint:::operatorí[(i-Ib); ) 


int lowO ( return lb; ? 
int highO f return lbásizeO-1; ) 


J; 


A Vector az alábbi módon használható: 


void gO 


t 
Vector v(1,109; // [1:10] tartomány 


for (int i - 1; i£—10; i43) f 
li — 7; 
ekes 


Ez az előző példához képest nem okoz többletterhelést. Világos, hogy a Vector változatot 
könnyebb olvasni és kisebb a hibázás lehetősége is. 


A felületosztályok rendszerint meglehetősen kicsik és kevés feladatot végeznek, de minde- 
nütt felbukkannak, ahol különböző hagyományok szerint megírt programoknak kell 
együttműködniük, mivel ilyenkor a különböző szabályok között közvetítésre van szükség. 
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A felületosztályokat gyakran használják például arra, hogy nem C-4- kódnak C-- felületet 
adjanak, és az alkalmazás kódját elszigeteljék a könyvtárakétól (nyitva hagyva egy könyv- 
tár másikkal való helyettesítésének a lehetőségén). 


A felületosztályok másik fontos felhasználási területe az ellenőrzött vagy korlátozott felüle- 
tek biztosítása. Nem szokatlan például, ha olyan egész típusú változóink vannak, melyek 
értéke csak egy adott tartományon belül mozoghat. Ez (futási időben) egy egyszerű sablon- 
nal kényszeríthető ki: 


templatecint low, int high: class Range f 
int val; 

bublic: 
class Errorf);  // kivételosztály 


RangeCint i) f AssertzErrorr(lowc-ik kizhigh); val — i; ) // lásd §24.3.7.2 
Range operator-(int i) f return "this-Range(1); ) 


operator int0 f return val; ) 
lős 
8 


void f((RangeS2, 1729; 
void g(RangeS-10, 1029; 


void h(int x) 


f 
Rangec0, 20017 i -— x; // Range::Error kivételt válthat ki 


inti1 — í; 


39; 
HD; // Range:: Error kivételt vált ki 


8-7); 
g(1009; // Range:: Error kivételt vált ki 


A Range sablon könnyen bővíthető úgy, hogy tetszőleges skalár típusú tartományok keze- 
lésére legyen képes (425.10[7D. 


Azokat a felületosztályokat, amelyek a más osztályokhoz való hozzáférést ellenőrzik vagy 
azok felületét igazítják, néha beburkoló (csomagoló, wrapper) osztályoknak nevezzük. 
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25.7. Leíró osztályok 


Az absztrakt típusok hatékony elválasztást biztosítanak a felületek és megvalósításaik kö- 
zött, de az absztrakt típus által adott felület és annak egy konkrét típus által nyújtott meg- 
valósítása közötti kapcsolat — ahogyan a §25.3-ban használtuk — tartós. Nem lehet például 
egy absztrakt bejárót az egyik forrásról (mondjuk egy halmazról átkötni egy másikra 
(mondjuk egy adatfolyamra), ha az eredeti forrás kimerült. 


Továbbá, hacsak nem mutatókon vagy referenciákon keresztül kezelünk egy absztrakt osz- 
tályt képviselő objektumot, elveszítjük a virtuális függvények előnyeit. A felhasználói kód 
függni fog a megvalósító osztályoktól, mivel az absztrakt típusok számára nem foglalható 
hely statikusan vagy a veremben (beleértve az érték szerinti paraméterátvételt is), anélkül, 
hogy tudnánk a típus méretét. A mutatók és hivatkozások használata azzal jár, hogy a tár- 
kezelés terhe a felhasználó kódra hárul. 


Az absztrakt osztályos megközelítés másik korlátja az, hogy az osztályobjektumok rögzített 
méretűek. Az osztályokat azonban fogalmak ábrázolására használjuk, melyek megvalósítá- 
sához különböző mennyiségű tárterület kell. 


E kérdések kezelésének kedvelt módja két részre osztani azt, amit egyetlen objektumként 
használunk. Az egyik lesz a felhasználói felületet adó leíró (handle), a másik pedig az áb- 
rázolás, amely az objektum állapotának egészét vagy annak java részét tárolja. A leíró és az 
ábrázolás közötti kapcsolatot általában egy, a leíróban levő mutató biztosítja. A leíróban az 
ábrázolásra hivatkozó mutatón kívül általában még van egy-két adat, de nem sok. Ebből kö- 
vetkezik, hogy a leíró szerkezete rendszerint stabil (még akkor is, ha az ábrázolás megvál- 
tozik), illetve hogy a leírók meglehetősen kicsik és viszonylag szabadon mozgathatók, így 
a felhasználónak nem kell mutatókat és referenciákat használnia. 








Leíró 47 Ábrázolás 
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A §11.12 String-je a leíró egyszerű példája. A leíró felületet, hozzáférés-szabályozást és tár- 
kezelést biztosít az ábrázolás részére. Ebben az esetben mind a leíró, mind az ábrázolás 
konkrét típusok, bár az ábrázoló osztály többnyire absztrakt osztály szokott lenni. 


Vegyük a §25.3-ból a Set absztrakt típust. Hogyan gondoskodhatunk számára egy leíróról és 
milyen előnyökkel, illetve hátrányokkal járhat ez? Egy adott halmazosztályhoz egyszerűen 
megadhatunk egy leírót, a -2 operátor túlterhelésével: 


templatexcilass T: class Set handle f 
SeIZT2? rep; 

bublic: 
SeIZT2? operator-0 ( return rep; ) 


Set handle(SetST:2? pp) : rep(pp) ( ; 
H 


Ez nem befolyásolja jelentősen a Set-ek használatának módját; egyszerűen Set handle-eket 
adunk át Seik-ek vagy Set"-ok helyett: 


void (Set handleczint: 5) 


( 
for Gnrt p - s-xfirstO; p; pb - 5 xnextO) 


S 
t 


) 
J 


VAA 


void userO 


( 


Set handleczint: si(new List setsint:); 
Set handlezint:- ucnew Vector. setsint-(100)9; 


HKSD; 
JO; 
) 


Gyakran többet kívánunk egy leírótól, mint hogy a hozzáférésről gondoskodjon. Például, 
ha a Set osztályt és a Set handle osztályt együtt tervezték, a hivatkozásokat könnyen meg- 
számlálhatjuk, ha minden Set-ben elhelyezünk egy használatszámlálót. Persze a leírót álta- 
lában nem akarjuk együtt tervezni azzal, aminek a leírója, így önálló objektumban kell tá- 
rolnunk minden adatot, amit a leírónak biztosítania kell. Más szóval, szükségünk lenne nem 
tolakodó (non-intensive) leírókra is a tolakodók mellett. Íme egy leíró, mely felszámol egy 
objektumot, amikor annak utolsó leírója is megsemmisül: 
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templatezclass X: class Handle f( 
XX" rep; 
int? pcount; 

bublic: 
X7 operator-:0 ( return rep; ) 


Handle(x? pp) : rep(pp), pcount(new int(1)) ( ) 
Handle(const Handleg r) : rep(r.rep), pcount(rpcount) ( Cpcount)---x; ? 


Handlek operator-(const Handlek r) 
í 
if (rep --— r.rep) return "this; 
if (-Cpcouny -- 0) f 
delete rep; 
delete pcount; 
J 
rep — r.rep; 
pcount - r.pcount; 
CpcounDr-; 
return "this; 


JÚ 


-Handile0 f if (--Cpcouny -—- 0) f delete rep; delete pcount; ) ? 


V/4ba 


J; 


Egy ilyen leíró szabadon átadható: 
void fi(HandlecsSet-); 


HandlecSet: [20 

( 
HandlecSet: h(new List setsint:); 
// ... 


return h; 


j 


void g0 

( 
HandlecSet: hh - f20; 
JINN); 
1... 


j 
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Itt az /20-ben létrehozott halmaz törlődik a g0-ből való kilépéskor — hacsak /70 fenn nem 
tartja annak egy másolatát. (A programozónak erről nem kell tudnia.) 


Természetesen ennek a kényelemnek ára van, de a használatszámláló tárolásának és fenn- 
tartásának költsége a legtöbb alkalmazásnál elfogadható. 


Néha hasznos az ábrázolásra hivatkozó mutatót a leíróból kinyerni és közvetlenül felhasz- 
nálni. Erre akkor lehet szükség, ha egy objektumot egy olyan függvénynek kell átadni, 
amely nem ismeri a leírókat. Ez a megoldás jól működik, feltéve, hogy a hívott függvény 
nem semmisíti meg a neki átadott objektumot vagy egy arra hivatkozó mutatót nem tárol 
a hívóhoz való visszatérés utáni használatra. Egy olyan művelet szintén hasznos lehet, 
amely a leírót egy új ábrázoláshoz kapcsolja: 


templatexclass X- class Handle f 


Ve 
X" get repO f return rep; ) 


void bind(X" pp) 
J 
t 
if (bp !- rep) ( 
if (-"pcount -- 0) ( 


delete rep; 

xpcount — 1; // pcount újrahasznosítása 
, 
else 

bcount - new int( 1; // új pcount 
rep - DD; 


) 
); 


Vegyük észre, hogy Handle-ből új osztályokat származtatni nem különösebben hasznos, ez 
ugyanis egy konkrét típus, virtuális függvények nélkül. Az alapelv, hogy egy bázisosztály 
által meghatározott teljes osztálycsaládhoz egyetlen leíró osztályunk legyen. Ebből a bázis- 
osztályból származtatni viszont már hasznos lehet. Ez a csomópont-osztályokra éppúgy ér- 
vényes, mint az absztrakt típusokra. 


Fenti formájában a Handle nem foglalkozik örökléssel. Ahhoz, hogy egy olyan osztályunk 
legyen, mely úgy működik, mint egy valódi használatszámláló, a Handle-t együtt kell hasz- 
nálni a §13.6.3.1 Ptr-jével (lásd §25.10[2D. 
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Az olyan leírót, melynek felülete közel azonos azon osztályéval, melynek leírója, gyakran 
nevezzük broxy-nak. Ez különösen azokra a leírókra vonatkozik, melyek távoli gépen lévő 
objektumokra hivatkoznak. 


25.7.1. A leírók műveletei 


A -2 operátor túlterhelése lehetővé teszi, hogy egy leíró minden hozzáféréskor megkapja 
a vezérlést, és valamilyen műveletet végezzen egy objektumon. A leírón keresztül hozzá- 
férhető objektum felhasználásainak számáról például statisztikát készíthetünk: 


template Sclass T- class Xhandle ( 
T" rep; 
int no of accesses; 
bublic: 
T" operator-:0 (f no of accessest; return rep; ) 


TT aa 


J; 


Azon leírók, melyeknél a hozzáférés előtt és után is valamilyen műveletet kell végezni, ki- 
dolgozottabb kódot igényelnek. Tegyük fel például, hogy egy olyan halmazt szeretnénk, 
amely zárolható, amíg beszúrás vagy eltávolítás folyik. Az ábrázoló osztály felületét lénye- 
gében meg kell ismételni a leíró osztályban: 


templatexclass T- class Set controller f 
SeIzT2? rep; 
Lock lock; 
LL étozó 
bublic: 
void insert(( T? p) f Lock ptr x(lock); rep-:insert(p); )  // lásd §14.4.1 
void remove( I" p) ( Lock ptr x(lock); rep-2remove(D9; ? 


int is memben(T" p) f return rep-:is member(D9; ) 


T get firstŐ ( T" p - rep-xfirstO; return p ? tp : TO; ) 
T get next0 ( T" p - rep-2nextO; return p ? "p : TO; ) 


T firstŐ ( Lock ptr x(lock); T tmp - "rep-2firstO; return tmp; )? 
T next0 ( Lock ptr x(lock); T tmp - "rep-2nextO; return tmp; ) 


Ms 
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Ezekről a továbbító függvényekről gondoskodni fáradságos (így hibát is véthetünk köz- 
ben), jóllehet nehézséget nem jelent és a futási időt sem növeli. 


Vegyük észre, hogy a Set-nek csak némelyik függvénye kíván zárolást. Tapasztalatom sze- 
rint általános, hogy egy elő- és utótevékenységeket igénylő osztály a műveleteket csak né- 
hány tagfüggvénynél kívánja meg. A minden műveletnél való zárolás — ahogy egyes rend- 
szerfigyelőknél lenni szokott — felesleges zárolásokhoz vezet és észrevehetően lassíthatja 
a párhuzamos végrehajtást. 


A leírón végzett műveletek alapos kidolgozásának előnye a -- operátor túlterhelésével 
szemben az, hogy a Set controller osztályból származtathatunk. Sajnos a leírók néhány elő- 
nyös tulajdonságát feladjuk, ha a származtatott osztályhoz adattagokat teszünk, mert a kö- 
zösen használt kód mennyisége az egyes leírókban levő kód mennyiségéhez viszonyítva 
csökken. 


25.8. Keretrendszerek 


A §25.2-425.7-ben leírt osztályfajtákból épített komponensek azáltal támogatják a kódterve- 
zést és -újrahasznosítást, hogy építőkockákat és kombinációs lehetőségeket biztosítanak. 
A programozók és az alkalmazáskészítő eszközök építik fel azt a vázat, amelybe ezek az 
építőkockák beleillenek. A tervezés és újrahasznosítás támogatásának egy másik, általában 
nehezebb módja egy olyan, közös vázat adó kód megírása, melybe az alkalmazáskészítő 
építőkockákként az adott alkalmazásra jellemző kódokat illeszti be. Ez az, amit általában 
keretrendszernek (application framework) hívunk. Az ilyen vázat biztosító osztályok felü- 
lete gyakran olyan , kövér", hogy hagyományos értelemben aligha nevezhetők típusoknak; 
inkább teljes alkalmazásnak tűnnek, bár nem végeznek semmilyen tevékenységet; azokat 
az alkalmazásprogramozó biztosítja. 


Példaképpen vegyünk egy szűrőt, vagyis egy olyan programot, amely egy bemeneti adat- 
folyamból olvas, majd annak alapján (esetleg) elvégez néhány műveletet, (esetleg) egy ki- 
meneti adatfolyamot hoz létre, és (esetleg) ad egy végeredményt. Első ötletünk bizonyára 
az, hogy a programhoz olyan keretrendszert készítsünk, amely olyan művelethalmazt ad 
meg, melyet egy alkalmazásprogramozó biztosít: 
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class Filter ( 


bublic: 
class Retry ( 
public: 
virtual const char" messageO f return O; ) 
b 


Azon fü 
(pure vi 


virtual void startO ( ? 
virtual int readŐ — 0; 
virtual void writeO ( ) 
virtual void compute0 f ) 
virtual int resultÓ — 0; 


virtual int retry(Retryk m) f cerr cz m.messageO cz Mn; return 2; ) 


virtual -FilterO f ) 


ggvényeket, melyeket a származtatott osztálynak kell biztosítania, tisztán virtuális 
rtual) függvényekként deklaráltuk; a többit egyszerűen úgy definiáltuk, mint amik 


nem végeznek műveletet. 


A keretr 


endszer gondoskodik egy főciklusról és egy kezdetleges hibakezelő eljárásról is: 


int main loop(Filter? p) 


( 


JorG;) ( 
try ( 
DP-ostartO; 
while (p-2xreadO) ( 
b--xcomputeO; 
b-2writeO; 
) 
return p-2resultO; 
) 


catch (Filter::Retryk m) ( 
if Gnt i - p-xretry (m)) return i; 


j 

catch (...) ( 
cerr 22 "Végzetes szűrőhibaNm "; 
return 1; 

J 
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A programot végül így írhatjuk meg: 


class My filter : public Filter f( 
istireamdá is; 
ostreamáz Os; 
int nchar; 
bublic: 
int readO f char c; is.get(c); return is.goodO; ) 
void computeO f ncharx-; ) 
int resultO f os c£ nchar cc " elolvasott karakterMn"; return O; ) 


My filterGistreamé ti, ostreamk 00) : is(ii), os(o0), nchar(0) f ? 


J; 
És így indíthatjuk el: 


int mainŐ 


( 
My filter (cin,cout); 
return main loop(kf9; 


J 


Természetesen ahhoz, hogy igazán hasznát vegyük, a keretrendszernek több szerkezetet és 
jóval több szolgáltatást kellene nyújtania, mint ebben az egyszerű példában. A keretrendszer 
általában csomópont-osztályokból álló hierarchia. Ha egy mélyen egymásba ágyazott ele- 
mekből álló hierarchiában az alkalmazásprogramozóval íratjuk meg a levél osztályokat, le- 
hetővé válik a közös elemek több program által való használata és a hierarchia által nyújtott 
szolgáltatások újrahasznosítása. A keretrendszert egy könyvtár is támogathatja, olyan osztá- 
lyokkal, melyek az alkalmazásprogramozó számára a műveletosztályok meghatározásánál 
hasznosnak bizonyulhatnak. 


25.9. Tanácsok 


[1] Az egyes osztályok használatára vonatkozóan hozzunk megfontolt döntéseket. 


425.1. 
[2] Óvakodjunk a választás kényszerétől, melyet az osztályok eltérő fajtái okoznak. 
425.1. 


[3] Egyszerű, független fogalmak ábrázolására használjunk konkrét típusokat. 425.2. 
[4] Használjunk konkrét típusokat azon fogalmak ábrázolására, melyeknél nélkü- 
lözhetetlen az optimálishoz közeli hatékonyság. §425.2. 
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[5] 
[6] 


[7] 
[8] 
[91] 
[10] 
[11] 
[12] 
[13] 
[14] 


[15] 
[16] 


[17] 
[18] 


25.10. 
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Konkrét osztályból ne származtassunk. §425.2. 

Használjunk absztrakt osztályokat olyan felületek ábrázolására, ahol az objektu- 
mok ábrázolása változhat. §425.3. 

Használjunk absztrakt osztályokat olyan felületek ábrázolására, ahol az objektu- 
mok különböző ábrázolásainak együtt kell létezniük. §25.3. 

A létező típusok új felületeinek ábrázolására használjunk absztrakt osztályokat. 
425.3. 

Ha hasonló fogalmak közösen használják a megvalósítás egyes részeit, használ- 
junk csomópont-osztályokat. §25.4. 

A megvalósítás fokozatos kidolgozásához használjunk csomópont-osztályokat. 
425.4. 

Az objektumok felületének kinyerésére használjunk futási idejű típusazonosí- 
tást. §25.4.1. 

Az állapothoz kapcsolódó műveletek ábrázolására használjunk osztályokat. 
$25.5. 

Azon műveletek ábrázolására, melyeket tárolni, átvinni, vagy késleltetni kell, 
használjunk osztályokat. 425.5. 

Ha egy osztályt új felhasználáshoz kell igazítani (az osztály módosítása nélkül, 
használjunk felületosztályokat. §25.6. 

Ellenőrzés hozzáadására használjunk felületosztályokat. 425.6.1. 

Használjunk leírókat, hogy elkerüljük a mutatók és referenciák közvetlen hasz- 
nálatát. §25.7. 

A közösen használt ábrázolások kezelésére használjunk leírókat. 425.7. 

Ha az alkalmazási terület lehetővé teszi, hogy a vezérlési szerkezetet előre meg- 
határozzuk, használjunk keretrendszert. §25.8. 


Gyakorlatok 


. CD A §25.4.1 Jo sablonja nem működik beépített típusokra. Módosítsuk úgy, 


hogy működjön. 


. 1.5) A §25.7 Handle sablonja nem tükrözi azon osztályok öröklési kapcsolatait, 


amelyeknek leírója. Módosítsuk úgy, hogy tükrözze (vagyis lehessen egy 
HandlecsCircle:-el egy HandlecsShape:-nek értéket adni, de nem fordítva). 


. C02.5) Ha adott egy String osztály, azt ábrázolásként használva és műveleteit vir- 


tuális függvényekként megadva hozzunk létre egy másik karakterlánc-osztályt. 
Hasonlítsuk össze a két osztály teljesítményét. Próbáljunk találni egy értelmes 
osztályt, amely a legjobban a virtuális függvényekkel rendelkező karakterlánc- 
osztályból történő nyilvános származtatással valósítható meg. 
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4) Tanulmányozzunk két széles körben használt könyvtárat. Osztályozzuk 

a könyvtári osztályokat konkrét típusokként, absztrakt típusokként, csomópont- 
osztályokként, leíró osztályokként, és felületosztályokként. Használnak-e 
absztrakt és konkrét csomópont-osztályokat? Van-e a könyvtárakban levő osztá- 
lyokra megfelelőbb osztályozás? Használnak-e kövér felületeket? Milyen tárke- 


zelési módot használnak? Milyen lehetőségek vannak — ha vannak - futási idejű 
típusinformációra? 


. C2) A Filter váz (§25.8) segítségével írjunk olyan programot, mely egy bemeneti 


adatfolyamból eltávolítja a szomszédos ismételt szavakat, majd az eredményt át- 
másolja a kimenetre. 


. C2) A Filter keretrendszer segítségével írjunk olyan programot, mely egy beme- 


neti adatfolyamban megszámlálja a szavak gyakoriságát és kimenetként gyakori- 
sági sorrendben felsorolja a (szó, szám) párokat. 


. C1.5) Írjunk egy Range sablont, mely sablonparaméterekként veszi át a tarto- 


mányt és az elemtípust. 


. C1) Írjunk egy Range sablont, mely a tartományt konstruktor-paraméterekként 


veszi át. 


. C2) Írjunk egy egyszerű karakterlánc-osztályt, mely nem végez hibaellenőrzést. 


írjunk egy másik osztályt, mely ellenőrzi az előbbihez való hozzáférést. Vitassuk 
meg az alapszolgáltatások és a hibaellenőrzés elválasztásának előnyeit és hátrá- 
nyait. 


10. (2.5) Készítsük el a §25.4.1 objektum [I/O rendszerét néhány típusra, köztük 


11. 


legalább az egészekre, a karakterláncokra és egy tetszőlegesen kiválasztott osz- 
tályhierarchiára. 

(2.5) Határozzuk meg a Storable osztályt, mint absztrakt bázisosztályt 

a write out és read inO virtuális függvényekkel. Az egyszerűség kedvéért té- 
telezzük fel, hogy egy perzisztens tárolóhely meghatározásához egy karakter- 
lánc elegendő. Használjuk fel a Szorage osztályt egy olyan szolgáltatásban, mely 
a Storable-ből származtatott osztályok objektumait írja lemezre és ugyanilyen 
objektumokat olvas lemezről. Ellenőrizzük néhány tetszés szerint választott osz- 
tállyal. 


12.C4) Hozzuk létre a Persistent alaposztályt a save) és no saveO műveletekkel, 


melyek egy destruktor által ellenőrzik, hogy egy objektum bekerült-e az állandó 
tárba. A saveO-en és no saveO-en kívül még milyen használható műveleteket 
nyújthatna a Persistenf?? Teszteljük a Persistent osztályt néhány tetszés szerint vá- 
lasztott osztállyal. Csomópont-osztály, konkrét típus, vagy absztrakt típus-e 
Persistenf? Miért? 


13. (3) Írjunk egy Stack osztályt, melynek megvalósítása futási időben módosítha- 


tó. Tipp: ,Egy újabb indirekció minden problémát megold." 
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14.C€3.5) Készítsük el az Oper osztályt, amely egy /d típusú (string vagy C stílusú ka- 
rakterlánc) azonosítót és egy műveletet (függvénymutatót vagy függvényobjektu- 
mot) tartalmaz. Határozzuk meg a Cat object osztályt, mely Oper-ek listáját és 
egy void"-ot tartalmaz. Lássuk el a Cat object-et egy add operCOper) művelettel, 
mely egy Oper-t ad a listához; egy remove operdd)-del, mely egy Id-del azonosí- 
tott Oper-t eltávolít a listából; valamint egy oberatorO (Id, arg)-gal, mely meghív- 
ja az Id-del azonosított Oper-t. Készítsünk egy Cat-eket tároló vermet egy 
Cat object segítségével. Írjunk egy kis programot ezen osztályok használatára. 

15.C3) Készítsünk egy Object sablont a Cat object osztály alapján. Használjuk fel 
az Object-et egy String-verem megvalósításához. Írjunk egy kis programot 
a sablon használatára. 

16. €2.5) Határozzuk meg az Object osztály Class nevű változatát, mely biztosítja, 
hogy az azonos műveletekkel rendelkező objektumok közös műveletsort hasz- 
náljanak. írjunk egy kis programot a sablon használatára. 

17.C2) Készítsünk egy olyan Stack sablont, mely egy, az Object sablon által megva- 
lósított verem részére egy hagyományos, típusbiztos felületről gondoskodik. 
Hasonlítsuk össze ezt a vermet az előző gyakorlatokban talált veremosztályok- 
kal. írjunk egy kis programot a sablon használatára. 

18. (3) Írjunk egy osztályt olyan műveletek ábrázolására, melyeket végrehajtásra 
egy másik gépre kell átvinni. Teszteljük egy másik gépnek ténylegesen elkül- 
dött parancsokkal vagy parancsoknak egy fájlba írásával, melyeket ezután a fájl- 
ból kiolvasva hajtunk végre. 

19. C2) Írjunk egy osztályt függvényobjektumok alakjában ábrázolt műveletek 
együttes használatára. Ha adott fés g függvényobjektum, a Compose(fg) hoz- 
zon létre egy olyan objektumot, mely egy g-hez illeszkedő x paraméterrel meg- 
hívható, és f(g(x09-et ad vissza, feltéve, hogy a g0 által visszaadott érték egy, az 
JO által elfogadható paramétertípus. 


Függelékek és tárgymutató 


A függelékek a C-t nyelvtanával; a C és a C4- között, valamint a szabványos és a szabvá- 
nyosítás előtti C-4-változatok között felmerülő kompatibilitási kérdésekkel; illetve a nyelv 
néhány egyéb szolgáltatásával foglalkoznak. Az igen részletes tágymutató a könyv lénye- 


ges része. 


Fejezetek 


Nyelvtan 

Kompatibilitás 

Technikai részletek 

Helyi sajátosságok 

Kivételbiztosság a standard könyvtárban 
Tárgymutató 


— lesi a) a 6 s 





Nyelvtan 


, Nincs nagyobb veszély, ami egy tanárra leselkedik, 
mint hogy szavakat tanít a dolgok helyett." 
(Marc Block) 


Bevezetés s Kulcsszavak es Nyelvi egységek s Programok "s Kifejezések e Utasítások e 
Deklarációk s Deklarátorok e Osztályok s Származtatott osztályok s Különleges tagfügg- 
vények e Túlterhelés s Sablonok s Kivételkezelés e Az előfeldolgozó direktívái 


A.1. Bevezetés 


A Cs34 szintaxisának (formai követelményeinek) itt található összefoglalása a megértés 
megkönnyítését célozza. Nem a nyelv pontos leírása a cél; az alább leírtaknál a C-t több 
érvényes nyelvtani szerkezetet is elfogad. Az egyszerű kifejezéseknek a deklarációktól va- 
ló megkülönböztetésére a többértelműség-feloldási szabályokat (§A.5, SA.7), a formailag 
helyes, de értelmetlen szerkezetek kiszűrésére pedig a hozzáférési, többértelműségi és tí- 
pusszabályokat együttesen kell alkalmaznunk. 
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A C és Cs szabvány a legkisebb különbségeket is formai különbségekkel és nem megszo- 
rításokkal fejezi ki. Ez nagyfokú pontosságot ad, de nem mindig javítja a kód olvashatóságát. 


A.2. Kulcsszavak 


A typedef(§4.9.7), névtér (48.2), osztály (10. fejezet), felsoroló típus (44.89), és template (13. 
fejezet) deklarációk új környezetfüggő kulcsszavakat vezetnek be a programba. 


tybedef-név: 
azonosító 


névtér-név: 
eredeti-névtér-név 


névtér-álnév 


eredeti-névtér-név: 
azonosító 


névtér-álnév: 
azonosító 

osztálynév: 
azonosító 


sablon-azonosító 


Jfelsorolásnév: 
azonosító 


sablonnév: 
azonosító 


Jegyezzük meg, hogy egy osztályt megnevező tybedef-név egyben osztálynév is. 


Ha nem adjuk meg kifejezetten egy azonosítóról, hogy egy típus neve, a fordító feltételezi, 
hogy nem típust nevez meg (lásd §C.13.59. 


A C3--- kulcsszavai a következők: 





A. Nyelvtan 1069 


C-1- 3 kulcsszavak 








and and eg asm auto bitand bitor 

bool break case catch char class 
compl const const cast continue default delete 

do double dynamic cast else enum explicit 
export extern Jalse jJfloat for Jjriend 
goto if inline int long mutable 
namespace new not not eg operator or 

or. eg brivate Pbrotected bublic register reinterpret cast 
return short signed sizeof static static cast 
struct switch template this throw true 

try typedef typeid typename — union unsigned 
using virtual void volatile wchar t while 

xor xor. eg 





A.3. Nyelvi egységek 


A szabványos C és C-t nyelvtanok a nyelvi egységeket nyelvtani szerkezetekként mutatják be. 
Ez növeli a pontosságot, de a nyelvtan , méretét" is, és nem mindig javítja az olvashatóságot: 


hex-guad: 
hexadecimális-számjegy hexadecimális-számjegy hexadecimális-számjegy hexadecimális-számjegy 


általános-karakternév: 
vu hex-guad 
MW hex-guad hex-guad 


előfeldolgozó-szimbólum: 
fejállomány-név 
azonosító 
bbp-szám 
karakterliterál 
karakterlánc-literál 
előfeldolgozó-utasítás-vagy-műveleti-jel 
minden nem üreshely karakter, ami nem tartozik a fentiek közé 


szimbólum: 
azonosító 
kulcsszó 
literál 
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operátor 
műveleti-jel 


Jfejállomány-név: 
ah-char-sorozat: 
"g-char-sorozat" 


h-char-sorozat: 
h-char 
h-char-sorozat h-char 


h-char: 
a forrás-karakterkészlet bármely tagja, kivéve az újsor és 2 karaktereket 


g-char-sorozat: 
g-char 
g-char-sorozat g-char 


g-char: 
a forrás-karakterkészlet bármely tagja, kivéve az újsor és " karaktereket 


bp-szám: 
számjegy 
. számjegy 
bp-szám számjegy 
bp-szám nem-számjegy 
bp-szám e előjel 
bbp-szám E előjel 
bp-szám . 





azonosító: 
nem-számjegy 
azonosító nem-számjegy 
azonosító számjegy 


nem-számjegy: a következők egyike 
általános-karakternév 

2 ráviB 6-d e ge 

A: BC DE F G.A 





számjegy: a következők egyike 
0 T.2 37-45 6728. 9 
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előfeldolgozó-utasítás-vagy-műveleti-jel: a következők egyike 
( ) [ ] tt tt ( ) £: :57  c8 852 $:5 
8: ; i 2 Bő j is TT s jj / 5 o 
§ ! il ! - 1 5 ha Éz Új; / 5 fe 
6. ! Es 2 né 55 ! 2 b 66 I] Tét 
-- j -5 szk ... new delete and and eg bitand 
bitor compl not or not eg xor or eg xor eg 
literál: 

egészliterál 

karakterliterál 

lebegőpontos-literál 

karakterlánc-literál 

logikai-literál 
egészlíterál: 


decimális-literál egész-utótag nem kötelező 
oktális-literál egész-utótag sem kötelező 


hexadecimális-literál egész-utótag nem kötelező 


decimális-literál: 
nem-nulla-számjegy 
decimális-literál számjegy 


oktális-literál: 
(0) 
oktális-literál oktális-számjegy 


hexadecimális-literál: 
0x hexadecimális-számjegy 
0X hexadecimális-számjegy 
hexadecimális-literál hexadecimális-számjegy 


nem-nulla-számjegy: a következők egyike 
d. 2, B. b Be SL A Br 9 


oktális-számjegy: a következők egyike 
Os 2 BE sás 


hexadecimális-számjegy: a következők egyike 
0 AR Z Zea, Bi A B 
áz bbi. söedi ser 
EL: BZ t-E. SD E 





egész-utótag: 
előjel-nélküli-utótag long-utótag em kötelező 
long-utótag előjel-nélküli-utótag em kötelező 
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előjel-nélküli-utótag: a következők egyike 
u U 


long-utótag: a következők egyike 
de s 


karakterliterál: 
tc-char-sorozat! 
Lc-char-sorozat" 


c-char-sorozat: 
c-char 
c-char-sorozat c-char 


c-char: 

a forrás-karakterkészlet bármely tagja, kivéve az egyszeres idézőjelet, a fordított berjelet, 
és az újsor karaktert 

escape-sorozat 

általános-karakternév 


escabe-sorozat: 
egyszerű-escape-sorozat 
oktális-escape-sorozat 
hexadecimális-escape-sorozat 


egyszerű-escape-sorozat: a következők egyike 


b AANENS VLZSNNN VEN 0 ERO — SÉRE 4 e SERT szét § a ll c: ezt V1ssllá S; 


oktális-escape-sorozat: 
v  oktális-számjegy 
v  oktális-számjegy oktális-számjegy 
Vv  oktális-számjegy oktális-számjegy oktális-számjegy 


hexadecimális-escabe-sorozat: 
vx  hexadecimális-számjegy 
hexadecimális-escape-sorozat hexadecimális-számjegy 


lebegőpontos-literál: 
tört-konstans kitevő-TÉSZ nem kötelező 


számjegy-sorozat kitevő-rész lebegőpontos-utótag rem köte 


lebegőpontos-utótag nem kötelező 


lező 


tört-konstans: 


számjegy-sorozat 


nem kötelező : Számjegy-sorozat 


számjegy-sorozat . 


kitevő-rész: 


e előjel, 


nem kötelező számjegy-sorozat 


E előjel, 


nem kötelező számjegy-sorozat 
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előjel: a következők egyike 
— — 


számjegy-sorozat: 
számjegy 
számjegy-sorozat számjegy 


lebegőpontos-utótag: a következők egyike 
£. 2 E d 


karakterlánc-literál: 

"s-char-sorozat , om kötelező . 
L"s-char-sorozat am kötelező. 
s-char-sorozat: 

s-char 

s-char-sorozat s-char 


s-char: 
a forrás-karakterkészlet bármely tagja, kivéve a kettős idézőjelet, a fordított perjelet, és az újsort 
escape-sorozat 
általános-karakternév 


logikai-literál: 
false 
true 


A.4. Programok 


A programok összeszetkesztés által összeállított fordítási egységek (translation unit) gyűjtemé- 
nyei (49.49. A fordítási egységek vagy másképp forrásfájlok, deklarációk sorozatából állnak: 


fordítási-egység: 


deklaráció-sorozat em kötelező 
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A.5. Kifejezések 


A kifejezéseket a 6. fejezet írja le és a §6.2 pont összegzi. A kifejezés-lista (expression-lisD 
definíciója azonos a kifejezésével (expression). A függvényparamétereket elválasztó vessző- 
nek a vessző operátortól (comma, seguencing operator, §6.2.2) való megkülönböztetésére 
két szabály szolgál. 


elsődleges-kifejezés: 
literál 
this 
: : azonosító 
: : oberátorfüggvény-azonosító 
: : minősített-azonosító 
( kifejezés ) 
azonosító-kifejezés 


azonosító-kifejezés: 
nem-minősített-azonosító 
minősített-azonosító 


nem-minősített-azonosító: 
azonosító 
operátorfüggvény-azonosító 
átalakítófüggvény-azonosító 
- osztálynév 
sablon-azonosító 


minősített-azonosító: 


beágyazott-név-meghatározás template nem-minősített-azonosító 


nem kötelező 
beágyazott-név-meghatározás: 

osztály-vagy-névtér-név : : beágyazott-név-meghatározáS rem kötelező 
osztály-vagy-névtér-név : : template beágyazott-név-meghatározás 


osztály-vagy-névtér-név: 
osztálynév 
névtér-név 


utótag-kifejezés: 
elsődleges-kifejezés 
utótag-kifejezés (I kifejezés ] 
utótag-kifejezés ( kifejezés-lista em kötelező ) 


egyszerű-típus-meghatározás ( kifejezés-lista em kötelező ) 


typename : : em kötelező Peágyazott-név-meghatározás azonosító ( kifejezés-lista, em kötelező ) 
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typename : : em kötelező Peágyazott-név-meghatározás template em kötelező 
sablon-azonosító ( kifejezés-liSId4 em kötelező ) 


utótag-kifejezés . template em kötelező "nem kötelező dZONosító-kifejezés 
utótag-kifejezés -2 templategem kötelező ::nem kötelező dZOnosító-kifejezés 
utótag-kifejezés . ál-destruktor-név 

utótag-kifejezés -—2 ál-destruktor-név 

utótag-kifejezés 4 

utótag-kifejezés —— 

dynamic-cast c típusazonosító 2 ( kifejezés ) 

static-cast c típusazonosító 2 ( kifejezés ) 
reinterpret-cast c típusazonosító 2 ( kifejezés ) 
const-cast c típusazonosító 2 ( kifejezés ) 

typeid ( kifejezés ) 

typeid ( típusazonosító ) 


kifejezés-lista: 
értékadó-kifejezés 
kifejezés-lista , értékadó-kifejezés 


ál-destruktor-név: 


: ! nem kötelező Peágyazott-név-meghatározásSnem kötelező Típusnév : : - típusnév 
: : nem kötelező Peágyazott-név-meghatározás template sablon-azonosító : : - típusnév 
: ! nem kötelező Peágyazott-név-meghatározáS nem kötelező " tibusnév 
egyoperandusú-kifejezés: 

utótag-kifejezés 

t-t cast-kifejezés 

-- cast-kifejezés 

egyoperandusú-operátor cast-kifejezés 

sizeof egyoperandusú-kifejezés 

sizeof ( típusazonosító ) 

new-kifejezés 

delete-kifejezés 


egyoperandusú-operátor: a következők egyike 
3 ba a - ! vs 


new-kifejezés: 


: : gem kötelező new elhelyező-utasítás rem kötelező 1ew-típusazonosító new-kezdőérték-adó, , am kötelező 


: : nem kötelező New elhelyező-utasítás, rem kötelező ( típusazonosító ) new-kezdőérték-adó, em kötelező 


elhelyező-utasítás: 
( kifejezés-lista ) 


new-típusazonosító: 


típus-meghatározó-sorozat new-deklarátor em kötelező 
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new-deklarátor: 
btr-operátor new-deklarátor em kötelező 


közvetlen-new-deklarátor 


közvetlen-new-deklarátor: 
I kifejezés 1 
közvetlen-new-deklarátor I konstans-kifejezés 1 


new-kezdőérték-adó: 
( kif ej ezés-liSta em kötelező ) 
delete-kifejezés: 
: ! nem kötelező delete cast-kifejezés 
: ! nem kötelező delete I ] cast-kifejezés 
cast-kifejezés: 
egyoperandusú-kifejezés 
( típusazonosító ) cast-kifejezés 


bm-kifejezés: 
cast-kifejezés 
bm-kifejezés . " cast-kifejezés 
bm-kifejezés -—27 cast-kifejezés 


szorzó-kifejezés: 
bm-kifejezés 
szorzó-kifejezés ? pm-kifejezés 
szorzó-kifejezés / pm-kifejezés 
szorzó-kifejezés 5 pm-kifejezés 


összeadó-kifejezés: 
szorzó-kifejezés 
összeadó-kifejezés 4 szorzó-kifejezés 
összeadó-kifejezés — szorzó-kifejezés 


eltoló-kifejezés: 
összeadó-kifejezés 
eltoló-kifejezés CZ összeadó-kifejezés 
eltoló-kifejezés 22 összeadó-kifejezés 


viszonyító-kifejezés: 
eltoló-kifejezés 
viszonyító-kifejezés c eltoló-kifejezés 
viszonyító-kifejezés - eltoló-kifejezés 
viszonyító-kifejezés c— eltoló-kifejezés 
viszonyító-kifejezés 2— eltoló-kifejezés 


A. Nyelvtan 


egyenértékűség-kifejezés: 
viszonyító-kifejezés 
egyenértékűség-kifejezés —— viszonyító-kifejezés 


egyenértékűség-kifejezés !—- viszonyító-kifejezés 


és-kifejezés: 
egyenértékűség-kifejezés 


és-kifejezés 6. egyenértékűség-kifejezés 


kizáró-vagy-kifejezés: 
és-kifejezés 
kizáró-vagy-kifejezés " és-kifejezés 


megengedő-vagy-kifejezés: 
kizáró-vagy-kifejezés 
megengedő-vagy-kifejezés ! kizáró-vagy-kifejezés 


logikai-és-kifejezés: 
megengedő-vagy-kifejezés 
logikai-és-kifejezés §.5. megengedő-vagy-kifejezés 


logikai-vagy-kifejezés: 
logikai-és-kifejezés 
logikai-vagy-kifejezés I I logikai-és-kifejezés 


feltételes-kifejezés: 
logikai-vagy-kifejezés 
logikai-vagy-kifejezés ? kifejezés : értékadó-kifejezés 


értékadó-kifejezés: 
feltételes-kifejezés 
logikai-vagy-kifejezés értékadó-operátor értékadó-kifejezés 
tIhrow-kifejezés 


értékadó-operátor: a következők egyike 
jó / 5 tk - 25 cz 6 8 








kifejezés: 
értékadó-kifejezés 
kifejezés , értékadó-kifejezés 


konstans-kifejezés: 
feltételes-kifejezés 
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A függvény stílusú típusátalakítások (cast) és a deklarációk hasonlóságából többértelműsé- 
gek adódhatnak. Például: 


int X; 


void JO 
( 
charCx); // x átalakítása char típusra 
// vagy egy x nevű char deklarációja? 


A fordító minden ilyen többértelmű szerkezetet deklarációként értelmez, vagyis a szabály: 
, ha lehet deklarációként értelmezni, akkor deklaráció". Például: 


TH(a)-m; // kifejezés-utasítás 
Ha); // kifejezés-utasítás 
TCeJGmt(319; // deklaráció 
TAI; // deklaráció 
Ha); // deklaráció 
T(a)-m; // deklaráció 
TCDJO; // deklaráció 
I(x)y,z7T; // deklaráció 


A többértelműség ilyen feloldása tisztán szintaktikus. A fordító a névről csak annyi informá- 
ciót használ fel, hogy az egy ismert típus- vagy sablonnév-e. Ha nem az, akkor ezektől kü- 
lönböző jelentést tételez fel róla. 


A template nem-minősített-azonosító szerkezet azt jelenti, hogy a nem-minősített- 
azonosító egy sablon neve, mégpedig egy olyan környezetben, ahonnan ezt nem lehetne 
levezetni (§C.13.0) 
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A.6. Utasítások 


Lásd §6.3-at. 


utasítás: 
címkézett-utasítás 
kifejezés-utasítás 
összetett-utasítás 
kiválasztó-utasítás 
ciklus-utasítás 
ugró-utasítás 
deklaráció-utasítás 
try-blokk 


címkézett-utasítás: 
azonosító : utasítás 
case konstans-kifejezés : utasítás 
default : utasítás 


kifejezés-utasítás: 


k ifi EJEZES nem kötelező 7 


összetett-utasítás: 

( utasítás-Sorozat em kötelező ) 
utasítás-sorozat: 

utasítás 

utasítás-sorozat utasítás 


kiválasztó-utasítás: 
if ( feltétel ) utasítás 
if ( feltétel ) utasítás else utasítás 
switch ( feltétel ) utasítás 


feltétel: 
kifejezés 
típus-meghatározás-sorozat deklarátor - értékadó-kifejezés 


ciklus-utasítás: 
while ( feltétel ) utasítás 
do utasításwhile ( kifejezés ) ; 


for ( for-init-utasítás feltétel 


nem kötelező " utasítás 


k if ejez ÉS nem kötelező ) 
for-init-utasítás: 

kifejezés-utasítás 

egyszerű-deklaráció 
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ugró-utasítás: 
break ; 
continue ; 
return kifejezés rem kötelező " 
goto azonosító ; 


deklaráció-utasítás: 
blokk-deklaráció 


A.7. Deklarációk 


A deklarációk szerkezetét a 4. fejezet írja le, a felsoroló típusokat (enumeration) a §44.8, 
a mutatókat (pointer) és tömböket (array) az 5. fejezet, a függvényeket (function) a 7. feje- 


zet, a névtereket (namespace) a §8.2, az összeszerkesztési direktívákat (inkage directive) 
a §9.2.4, a tárolási módokat (storage class) pedig a §10.4. 


deklaráció-sorozat: 
deklaráció 
deklaráció-sorozat deklaráció 


deklaráció: 
blokk-deklaráció 
függvénydefiníció 
sablondeklaráció 
explicit-béldányosítás 
explicit-specializáció 
összeszerkesztési-mód 
névtér-definíció 


blokk-deklaráció: 
egyszerű-deklaráció 
asm-definíció 
névtér-álnév-definíció 
using-deklaráció 
using-utasítás 


egyszerű-deklaráció: 


deklaráció-meghatározás-sorozat em kötelező kezdőérték-deklarátor-lista em kötelező ; 
deklaráció-meghatározás: 

tárolási-mód-meghatározás 

típus-meghatározás 


függvény-meghatározás 


friend 
typedef 


deklaráció-meghatározás-sorozat: 
deklaráció-meghatározás-sorozat 


tárolási-mód-meghatározás: 


auto 
register 
static 
extern 
mutable 


függvény-meghatározás: 


inline 
virtual 
explicit 


typedef-név: 


azonosító 


típus-meghatározás: 
egyszerű-típus-meghatározás 
osztály-meghatározás 
felsorolás-meghatározás 
összetett-típus-meghatározás 


cv-minősítő 


egyszerű-típus-meghatározás: 


nem kötelező 
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deklaráció-meghatározás 


: ! nem kötelező beágyazott-név-meghatározáS nem kötelező Típusnév 


: :! nem kötelező 
char 
wchar t 
bool 
short 

int 

long 
signed 
unsigned 
float 
double 
void 


típusnév: 


osztálynév 
felsorolásnév 
typedef-név 


beágyazott-név-meghatározás template 


nem kötelező 
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sablon-azonosító 
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összetett-típus-meghatározás: 


osztálykulcs : : nem kötelező Peágyazott-név-meghatározásSnem kötelező dZOnosító 

enum : : nem kötelező Peágyazott-név-meghatározásS rem kötelező dZONOSíÍtó 

typename : : em kötelező Peágyazott-név-meghatározás azonosító 

typename : : em kötelező Peágyazott-név-meghatározás template em kötelező Sablon-azonosító 


Jfelsorolásnév: 


azonosító 


Jfelsorolás-meghatározás: 


enum azonosító em kötelező ( felsorolás-lista nem kötelező ) 


Jfelsorolás-lista: 


felsoroló-definíció 
felsorolás-lista , felsoroló-definíció 


Jfelsoroló-definíció: 


felsoroló 
felsoroló — konstans-kifejezés 


felsoroló: 


azonosító 


névtér-név: 


eredeti-névtér-név 
névtér-álnév 


eredeti-névtér-név: 


azonosító 


névtér-definíció: 


nevesített-névtér-definíció 
nevesítetlen-névtér-definíció 


nevesített-névtér-definíció: 


eredeti-névtér-definíció 
bővített-névtér-definíció 


eredeti-névtér-definíció: 


namespace azonosító ( névtér-törzs ) 


bővített-névtér-definíció: 


namespace eredeti-névtér-név ( névtér-törzs ) 


nevesítetlen-névtér-definíció: 


namespace ( névltér-törzs ) 
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névtér-törzs: 
deklaráció-sorozat em kötelező 
névtér-álnév: 
azonosító 


névtér-álnév-definíció: 
namespace azonosító — minősített-névtér-meghatározás ; 


minősített-névtér-meghatározás: 


: : nem kötelező Peágyazott-név-meghatározásSnem kötelező 1Évtér-név 


using-deklaráció: 

using typenamegem kötelező : : nem kötelező Peágyazott-név-meghatározás nem- 
minősített-azonosító ; 

using :: nem-minősített-azonosító ; 


using-utasítás: 


using namespace : : nem kötelező Deágyazott-név-meghatározásSnem kötelező HÉvtér-név ; 


asm-definíció: 
asm ( karakterlánc-literál ) ; 


összeszerkesztési-mód: 
extern karakterlánc-literál ( deklaráció-sorozat, em kötelező ) 


extern karakterlánc-literál deklaráció 


A nyelvtan megengedi a deklarációk tetszőleges egymásba ágyazását, de bizonyos megszo- 
rítások érvényesek. Például nem szabad függvényeket egymásba ágyazni, azaz egy függvé- 
nyen belül egy másik függvényt kifejteni. 


A deklarációkat kezdő meghatározások ( minősítők", specifier) listája nem lehet üres (azaz 
, nincs implicit int", §B.2) és a meghatározások leghosszabb lehetséges sorozatából áll. Például: 


typedef int I; 
void (unsigned DT/"... 77) 


Itt /0 paramétere egy unsigned int. 


Az asmO szerkezet az assembly kód beszúrására szolgál. Jelentését az adott nyelvi változat 
határozza meg, de célja az, hogy a megadott helyen az adott szövegnek megfelelő assembly 
kód kerüljön be a fordító által létrehozott kódba. 
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Ha egy változót register-ként vezetünk be, azzal azt jelezzük a fordítóprogram számára, 
hogy a gyakori hozzáférésekre kell optimalizálnia a kódot. Az újabb fordítóprogramok leg- 
többje számára ezt felesleges megadni. 


A.7.1. Deklarátorok 


Lásd a §4.9.1 pontot, az 5. fejezetet (mutatók és tömbök), a §7.7 pontot (függvénymutatók) 
és a §15.5 pontot (tagokra hivatkozó mutatók). 


kezdőérték-deklarátor-lista: 
kezdőérték-deklarátor 


kezdőérték-deklarátor-lista , kezdőérték-deklarátor 


kezdőérték-deklarátor: 
deklarátor kezdőérték-adó em kötelező 


deklarátor: 
közvetlen-deklarátor 
btr-operátor deklarátor 


közvetlen-deklarátor: 
deklarátor-azonosító 
közvetlen-deklarátor ( paraméter-deklaráció-záradék ) cv-minősítő-sorozat em kötelező 
kivétel-meghatározásS em kötelező 


közvetlen-deklarátor I konstans-kifejezéS sem kötelező )] 


( deklarátor ) 


bir-operátor: 
Hi ág tazégés 
cv-minősítóő-sorozat rem kötelező 
5 
: :! nem kötelező Peágyazott-név-meghatározás " cv-minősító-sorozdat em kötelező 


cv-minősítő-sorozat: 
cv-minősítő cv-minősítő-sorozat nem kötelező 


cv-minősítő: 
const 
volatile 


deklarátor-azonosító: 
: : nem kötelező dzonosító-kifejezés 


: : nem kötelező beágyazott-név-meghatározáS sem kötelező TÍpusnév 
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típusazonosító: 
típus-meghatározás-sorozat elvont-deklarátor em kötelező 


típus-meghatározás-sorozat: 
típus-meghatározás típus-meghatározás-Sorozat em kötelező 


elvont-deklarátor: 
btr-operátor elvont-deklarátor , am kötelező 


közvetlen-elvont-deklarátor 


közvetlen-elvont-deklarátor: 
közvetlen-elvont-deklarátor em kötelező ( Paraméter-deklaráció-záradék ) cv-minősítő- 
kivétel-meghatározáS sem kötelező 


SOTOZAL em kötelező 


közvetlen-elvont-deklarátor em kötelező I konstans-kifejezésS rem kötelező )] 


( elvont-deklarátor ) 


baraméter-deklaráció-záradék: 
baraméter-deklaráció-lista em kötelező " " " nem kötelező 
baraméter-deklaráció-lista , 


baraméter-deklaráció-lista: 
baraméter-deklaráció 
baraméter-deklaráció-lista , paraméter-deklaráció 


baraméter-deklaráció: 
deklaráció-meghatározás-sorozat deklarátor 
deklaráció-meghatározás-sorozat deklarátor - értékadó-kifejezés 
deklaráció-meghatározás-sorozat elvont-deklarátor em kötelező 


deklaráció-meghatározás-sorozat elvont-deklarátor em kötelező — értékadó-kifejezés 


függvénydefiníció: 

deklaráció-meghatározás-sorozat em kötelező deklarátor ctor-kezdőérték-adó, , am kötelező 
függvénytörzs 

deklaráció-meghatározás-sorozat nem kötelező deklarátor függvény-try-blokk 


függvénytörzs: 
összetett-utasítás 


kezdőérték-adó: 
- kezdőérték-adó-záradék 
( kifejezés-lista ) 


kezdőérték-adó-záradék: 
értékadó-kifejezés 


( kezdőérték-lista , nem kötelező ) 


(1) 
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kezdőérték-lista: 
kezdőérték-adó-záradék 


kezdőérték-lista , kezdőérték-adó-záradék 


A volatile meghatározás/minősítés azt jelzi a fordítóprogram számára, hogy az objektum 
a nyelv által nem meghatározott módon változtatja az értékét, így az ,agresszív optimalizá- 
lás" kerülendő. Egy valósidejű órát például így deklarálhatunk: 


extern const volatile clock; 


A clock két egymást követő leolvasása különböző eredményeket adhat. 


A.8. Osztályok 


Lásd a 10. fejezetet. 


osztálynév: 
azonosító 
sablon-azonosító 


osztály-meghatározás: 
osztályfej ( tag-meghatározásS nem kötelező ) 


osztályfej: 


osztálykulcs azonosító rem kötelező alab-záradéR rem kötelező 


osztálykulcs beágyazott-név-meghatározás azonosító alap-záradék em kötelező 


osztálykulcs beágyazott-név-meghatározás template sablon-azonosító alap-záradék, em kötelező 


osztálykulcs: 
class 
struct 
union 


1ag-meghatározás: 
tag-deklaráció tag-meghatározásS nem kötelező 


hozzáférés-meghatározás : tag-meghatározásS nem kötelező 
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tag-deklaráció: 
deklaráció-meghatározás-sorozat 
J tigg vény def iníció ; nem kötelező 
: : sem kötelező Deágyazott-név-meghatározás template 


nem kötelező 148 -deklarátor-lista, em kötelező " 


nem kötelező 1em-minősített-azonosító ; 


using-deklaráció 
sablondeklaráció 


1ag-deklarátor-lista: 
1ag-deklarátor 
1ag-deklarátor-lista , tag-deklarátor 


1ag-deklarátor: 


deklarátor tires-meghatározáS nem kötelező 


deklarátor konstans-kezdőérték-adó sem kötelező 


azonosító, 


nem kötelező : Rkonstans-kifejezés 


üres-meghatározás: 
z 0 


konstans-kezdőérték-adó: 
- konstans-kifejezés 


A C-vel való összeegyeztethetőséget megőrzendő egy azonos nevű osztály és egy nem-osz- 
tály ugyanabban a hatókörben is deklarálható (§5.79. Például: 


struct stat (/5... 7) 
int stat(char" név, struct stat" buf); 


Ebben az esetben a sima név (staD a nem-osztály neve. Az osztályra egy osztálykulcs elő- 


taggal (class, struct vagy union) kell hivatkozni. 


A konstans kifejezéseket a §C.5 pont írja le. 


A.8.1. Származtatott osztályok 


Lásd a 12. és 15. fejezetet. 


alap-záradék: 
: alap-meghatározás-lista 


alap-meghatározász-lista: 
alap-meghatározás 
alap-meghatározás-lista , alap-meghatározás 
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alap-meghatározás: 


: : nem kötelező Peágyazott-név-meghatározás em kötelező OSZtálynév 
virtual hozzáférés-meghatározásS em kötelező : : nem kötelező Peágyazott-név- 


meghatározás em kötelező OSZtálynév 
hozzáférés-meghatározás virtual nem kötelező : : nem kötelező Peágyazott-név- 
meghatározás em kötelező OSZtálynév 
hozzáférés-meghatározás: 
private 
protected 


public 


A.8.2. Különleges tagfüggvények 


Lásd a §11.4 (átalakító operátorok), §10.4.6 (osztálytagok kezdeti értékadása) és §12.2.2 
(alaposztályok kezdeti értékadása) pontokat. 


átalakítófüiggvény-azonosító: 
operator átalakítás-típbusazonosító 


átalakítás-típusazonosító: 

típus-meghatározás-sorozat átalakítás-deklarátor am kötelező 
átalakítás-deklarátor: 

Pbtr-operátor átalakítás-deklarátor nem kötelező 


ctor-kezdőérték-adó: 


: mem-kezdőérték-lista 
mem-kezdőérték-lista: 

mem-kezdőérték-adó 

mem-kezdőérték-adó , mem-kezdőrték-lista 


mem-kezdőérték-adó: 
mem-kezdőérték-adó-azonosító ( kifejezés-lista em kötelező ) 
mem-kezdőérték-adó-azonosító: 
: ! nem kötelező beágyazott-név-meghatározásS rem kötelező OSZtálynév 
azonosító 
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A.8.3. Túlterhelés 
Lásd a 11. fejezetet. 

operátorfüggvény-azonosító: 

operator operátor 

operátor: a következők egyike 

new delete new[] deletel[] 

4 - k 7 s 8 § ! ! S az 

§ ai § / 5 ia 6 l cz BB. ne A 

iz, S$6 .BÉo ke ni kk —— j -sx -s () [1 


A.9. Sablonok 


A sablonokkal a 13. fejezet és a §C.13. pont foglalkozik részletesen. 


sablondeklaráció: 


export template c sablonparaméter-lista 2 deklaráció 


nem kötelező 

sablonparaméter-lista: 
sablonparaméter 
sablonparaméter-lista , sablonparaméter 


sablonparaméter: 
típus-baraméter 
baraméter-deklaráció 


típus-baraméter: 
class azonosító em kötelező 


class azonosító -— típusazonosító 


nem kötelező 
typename azonosító em kötelező 


typename azonosító — típusazonosító 


nem kötelező 
template c sablonparaméter-lista 2 class azonosító em kötelező 


template c sablonparaméter-lista : class azonosító - sablonnév 


nem kötelező 
sablon-azonosító: 


sablonnév c sablonargumentum-lista pl 


nem kötelező 


sablonnév: 
azonosító 
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sablonargumentum-lista: 
sablonargumentum 
sablonargumentum-lista , sablonargumentum 


sablonargumentum: 
értékadó-kifejezés 
típusazonosító 
sablonnév 


explicit-példányosítás: 
template deklaráció 


explicit-specializáció: 


template c 5 deklaráció 


Az explicit sablonargumentum-meghatározás egy érdekes többértelműségre ad lehetősé- 
get. Vegyük a következő példát: 


void hO 
( 
JETP(09; // többértelmű: ((D21) : (0) vagy (J2120) ? 
// feloldása: f£1- meghívása a 0 paraméterrel 
J 


A feloldás egyszerű és hatékony: ha fegy sablon neve, akkor /£ egy minősített sablonnév 
kezdete és az azt követő nyelvi egységek eszerint értelmezendőek; ha nem ez a helyzet, a c 
jel a ,kisebb mint" műveletet jelenti. Ugyanígy az első pár nélküli : jel lezárja a sablonpara- 
méterek listáját. Ha a nagyobb mint" jelre van szükségünk, zárójelezést kell alkalmaznunk: 


JE azb x(09; // szintaktikus hiba 
JE (a2b) x(09; // rendben 


Hasonló többértelműség léphet fel, ha a záró : jelek túl közel kerülnek: 


listgvectorsint:5 lvI; — // szintaktikus hiba: nem várt 5: (jobbra léptetés) 
list vectorsint: 2 lv2; // helyes: vektorok listája 


Figyeljünk a szóközre a két : jel között (a 532 a jobbra léptető operátor), mert nagyon 
könnyű elnézni. 
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A.10. Kivételkezelés 


Lásd a §8.3 pontot és a 14. fejezetet. 


try-blokk: 
try összetett-utasítás kezelő-sorozat 


Jüggvény-try-blokk: 
try ctor-kezdőérték-adó, , om kötelező függvénytörzs kezelő-sorozat 


kezelő-sorozat: 

kezelő kezelő-sorozat em kötelező 
kezelő: 

catch ( kivétel-deklaráció ) összetett-utasítás 


kivétel-deklaráció: 
típus-meghatározás-sorozat deklarátor 
típus-meghatározás-sorozat elvont-deklarátor 
típus-meghatározás-sorozat 


throw-kifejezés: 
throw értékadó-kifejezéS rem kötelező 


kivétel-meghatározás: 
throw ( típusazonosító-lista nem kötelező ) 


típusazonosító-lista: 
típusazonosító 
típusazonosító-lista , típusazonosító 


A.11. Az előfeldolgozó direktívái 


Az előfeldolgozó (preprocessor, pp) egy viszonylag egyszerű makró-feldolgozó rendszer, 
amely elsődlegesen nyelvi egységeken és nem egyes karaktereken dolgozik. A makrók 
meghatározásának és használatának (§7.8) képességén kívül az előfeldolgozó a szövegfáj- 
loknak és szabványos fejállományoknak (49.2.1) a forrásba építésére is lehetőséget ad és 
makrókon alapuló feltételes fordítást is tud végezni (§9.3.3). Például: 
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átif OPT--4 

tinclude "fejállományá.h" 
telif OZOPT 

tinclude "fejállomány.h" 
Áelse 

$includezcstdlib: 

endif 


Az összes előfeldolgozói utasítás (direktíva) a 7 jellel kezdődik, amelynek az első nem 
üreshely karakternek kell lennie a sorban. 


előfeldolgozó-fájl: 
csoport nem kötelező 
csoport: 
csoport-rész 
csoport csoport-rész 


csoport-rész: 
bbp-szimbólumotRzem kötelező ÚJSOT 
if-rész 
vezérlősor 


if-rész: 


if-csoport elif-csoportok, else-csoport, 


nem kötelező endif-sor 


nem kötelező 
if-csoport: 

t if konstans-kifejezés újsor csoport em kötelező 
t ifdef azonosító újsor CSODOTt em kötelező 
$t ifndef azonosító újsor CSODOTt em kötelező 
elif-csoportok: 

elif-csoport 

elif-csoportok elif-csoport 


elif-csoport: 

elif konstans-kifejezés újsor CSODOTt, am kötelező 
else-csoport: 

else újsor CsODOrt em kötelező 


endif-sor: 
endif újsor 
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vezérlősor: 
include pp-szimbólumok újsor 


define azonosító helyettesítő-lista újsor 
define azonosító balzárójel azonosító-lista, em kötelező ) helyettesítő-lista újsor 


undef azonosító újsor 

line pp-szimbólumok újsor 

error bp-szimbólumokR em kötelező ÚJSOT 
pragma pp-szimbólumotR, em kötelező ÚJSOT 








újsor 


balzárójel: 
a bal oldali zárójel karakter megelőző üreshely nélkül 


helyettesítő-lista: 
DD-sz imbólumok, nem kötelező 


bp-szimbólumok: 
előfeldolgozó-szimbólum 
bp-szimbólumok előfeldolgozó-szimbólum 


újsor: 

újsor karakter 
azonosító-lista: 

azonosító 

azonosító-lista , azonosító 


Kompatibilitás 


, Te mész a te utadon, a te 
szokásaid szerint, és én ís kö- 
vetem a saját elveimet." 

(C. Napier) 


C/Cr4 kompatibilitás s , Észrevétlen" különbségek a C és a Cr között s C program, ami 
nem Ct4-4 program "e Elavult szolgáltatások e C-4- program, ami nem C program "e Régebbi 
C-4-4-változatok használata s Fejállományok s A standard könyvtár 9" Névterek s Helyfog- 
lalási hibák s Sablonok e A for utasítás kezdőérték-adó része s Tanácsok s Gyakorlatok 


B.1. Bevezetés 


Ebben a függelékben azokat a különbségeket vizsgáljuk meg, amelyek a C és a C-t, illet- 
ve a szabványos C-t és a régebbi C---változatok között állnak fenn. Célunk az, hogy egy- 
részt leírjuk azokat a különbségeket, amelyek a programozóknak problémát okozhatnak, 
másrészt módszereket mutassunk ezen problémák kezelésére. A legtöbb kompatibilitási 
problémával akkor kerülünk szembe, amikor egy C programot a C-t--ból akarunk használ- 
ni, vagy egy nem szabványos C-- rendszerben létrehozott programot egy másik környezet- 
be akarunk átvinni, esetleg új lehetőségeket akarunk egy régebbi C----változatban használ- 
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ni. A cél nem az, hogy részletesen bemutassuk az összes kompatibilitási problémát, ami va- 
laha is előfordulhat, hanem az, hogy a leggyakoribb problémákra szabványos megoldást 
adjunk. 


Amikor kompatibilitási problémákról beszélünk, a legfontosabb kérdés az, hogy progra- 
munk a különböző nyelvi változatok milyen széles körében képes működni. A C$-4 nyelv 
megismeréséhez érdemes a legteljesebb és legkényelmesebb rendszert használnunk, rend- 
szerfejlesztéskor azonban ennél konzervatívabb stratégiát kell követnünk, hiszen olyan 
programot szeretnénk, amely a lehető legtöbb környezetben működőképes. Régebben ez 
nagyon jó kifogás volt arra, hogy a C4- ,túl fejlettnek" minősített lehetőségeit elkerüljük. 
Az egyes változatok azonban közeledtek egymáshoz, így a különböző platformok közötti 
hordozhatóság követelménye ritkán igényel olyan komoly erőfeszítéseket a programozó- 


tól, mint néhány évvel ezelőtt. 


B.2. C/C-t -- kompatibilitás 


Kisebb kivételektől eltekintve a Ct- a C nyelv továbbfejlesztésének tekinthető. A legtöbb 
különbség a C4-4 hangsúlyozottabb típusellenőrzéséből következik. A jól megírt C progra- 
mok általában C-t programok is. A C és C4-4 közötti összes különbséget a fordítónak is je- 
leznie kell. 


B.2.1. ,Észrevétlen" különbségek 


Néhány kivételtől eltekintve azok a programok, melyek C és Ct- nyelven is értelmezhetők, 
ugyanazt jelentik mind a két nyelvben. Szerencsére azok a különbségek, melyek mégis elő- 
fordulnak, általában csak árnyalatnyiak: 


A C-ben a karakterkonstansok és a felsoroló típusok mérete sizeof(int). A C-r-rt-ban 
sizeof(a) egyenértékű sizeof(char)-ral, a felsoroló típusok megvalósításához pedig az 
egyes Ct-4-változatok olyan méretet használhatnak, ami az adott környezetben a legcélsze- 
rűbb (44.99. 

A Cs4 lehetővé teszi a / jellel bevezetett megjegyzések használatát; ez a C-ben nem áll ren- 
delkezésünkre (bár nagyon sok C-változat tartalmazza bővítéskénb. Ezt az eltérést olyan 
programok készítéséhez használhatjuk fel, melyek a két nyelvben különbözőképpen visel- 
kednek. 
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Például: 


int (int a, int b) 
t 
return a //" elég valószínűtlen 7 b 
b /7 pontosvessző a szintaktikus hiba elkerülésére 7 


J 


Az ISO C ma már a Ct--hoz hasonlóan megengedi a // használatát. 


Egy belső hatókörben bevezetett adatszerkezet-név elrejtheti egy külső hatókörben dekla- 
rált objektum, függvény, felsorolás, vagy típus nevét: 


int x[99]; 
void JO 
( 
struct x ( int a; ]; 
sizeot(x); /7 a tömb mérete C-ben, a struct mérete Ct1-ban 7 


B.2.2. C program, ami nem C-t program 


A leggyakrabban problémát okozó különbségek általában nem túl élesek. A legtöbbet ezek 
közül a fordítók is könnyen észreveszik. Ebben a pontban olyan C kódokat mutatunk be, 
amelyek nem C-r- kódok. Ezek legtöbbjét már az újabb C-változatok is , rossz stílusúnak" , 


sőt , elavultnak" minősítik. 


A C-ben a legtöbb függvényt deklarálásuk előtt is meghívhatjuk: 


mainŐ /"rossz stílus C-ben, hibás C----ban 7 
t 
double sg2 — sgrt2; /" deklarálatlan függvény meghívása 7 
brintfCthe sguare root of 2 is 9gw",sg29; /" deklarálatlan függvény meghívása 7 
4 


A függvény-deklarációk (függvény-prototípusok) teljes és következetes használata minden 
C-megvalósításban ajánlott. Ha ezt a tanácsot megfogadjuk (és ezt a fordítók általában va- 
lamilyen kapcsolóval biztosítani is tudják), C programjaink illeszkedni fognak a C-t szabá- 
lyaihoz. Ha deklarálatlan függvényeket hívunk meg, nagyon pontosan ismernünk kell C 
rendszerünk függvényhívással kapcsolatos szabályait, hogy eldönthessük, okoztunk-e hi- 
bát vagy hordozhatósági problémát. Az előbbi main program például legalább két hibát 
tartalmaz C programként is. 


1098 Függelékek és tárgymutató 


A C-ben azok a függvények, melyeket paramétertípus megadása nélkül vezetünk be, tet- 
szőleges számú és típusú paraméterrel meghívhatók. Az ilyen függvényhasználat a Stan- 
dard C-ben is elavult, ennek ellenére sok helyen találkozhatunk vele: 

void fO;  /" a paramétertípusokat elhagyjuk 7 

void g0 

€ 

HD; /7 rossz stílus C-ben, hibás C--4-ban 7 
J 


A C-ben megengedett az a függvény-meghatározási forma, melyben a paraméterek típusát 
a paraméterek listájának megadása után rögzítjük: 


void (ap,c) char "p; char c; (/7 ... 7] /" helyes C-ben, hibás C44-ban 7 
Ezeket a definíciókat át kell írnunk: 


void f(int a, char" p, char c) (/5... 7] 


A C-ben és a Cst szabványosítás előtti változataiban az int alapértelmezett típus volt. Pél- 
dául: 


const a — 7; /5 C-ben "int" típust feltételez; C44-ban hibás 7 
Az ISO C€, a Cs--hoz hasonlóan, megtiltotta az , implicit int használatát. 


A C megengedi, hogy a visszatérési típusok és a paramétertípusok deklarációiban szruct- 
okat adjunk meg: 


struct S ( int x,y; ) fO; /t helyes C-ben, hibás C43-ban 7 
void g(struct S ( int x,y; ) 9; /" helyes C-ben, hibás C44-ban 7 


A Cs típus-meghatározásokra vonatkozó szabályai az ilyen deklarációkat feleslegessé te- 
szik és nem is engedik meg. 


A C-ben a felsoroló típusú változóknak értékül adhatunk egészeket is: 


enum Direction ( up, down J; 
Direction d — 1; /7t hiba: int értékadás Direction-nek; C-ben helyes 7 
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A C44 sokkal több kulcsszót ismer, mint a C. Ha ezek valamelyikét azonosítóként használ- 
juk egy C programban, kénytelenek leszünk azt lecserélni, hogy C---ban is értelmezhető 


programot kapjunk. 





C-t-- kulcsszavak, melyek a C-ben nem kulcsszavak 








and and eg asm bitand bitor bool 

catch class compl const cast delete dynamic cast 
explicit export Jalse Jfriend inline mutable 
namespace new not not eg operator or 

or. eg brivate brotected public reinterpret cast static cast 
template this throw true try typeid 
typename — using virtual wchar t XxoOTr xor. eg 











A C-ben néhány Ct- kulcsszó makróként szerepel a szabványos fejállományokban: 





C-H- kulcsszavak, melyek C makrók 





and and eg bitand bitor compl not 


not eg or or. eg wchar t XOT xor. eg 





Ez azt is jelenti, hogy a C-ben ezeket tesztelhetjük az si/defsegítségével, meghatározásukat 
felülbírálhatjuk stb. 


A C-ben a globális adatobjektumokat többször is deklarálhatjuk egy fordítási egységen be- 
lül, anélkül, hogy az extern kulcsszót használnánk. Amíg a deklarációk közül csak egy ad 


kezdőértéket, a fordító az objektumot egyszer meghatározottnak (egyszer definiáltnak) 
tekinti. 
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Például: 
int í; int i; /" egyetlen ti! egészet határoz meg vagy vezet be; C4-4-ban hibás 7 
A C44-ban minden elemet csak egyszer határozhatunk meg (49.2.3). 


A C44-ban egy osztálynak nem lehet ugyanaz a neve, mint egy typedef elemnek, amely 
ugyanabban a hatókörben valamilyen más típusra hivatkozik (§5.7). 


A C-ben a void" használható bármilyen mutató típusú változó egyszerű vagy kezdeti érték- 
adásának jobb oldalán. A Ct-4-ban ezt nem tehetjük meg (§5.6.): 


void f(int n) 
t 


int" p - mallocín"sizeof(in)); /7C44-ban hibás; használjuk inkább a new! 


operátort "/ 
J 


A C megengedi, hogy ugrásokkal kikerüljünk egy kezdeti értékadást, a Ct-t-ban ez sem 
lehetséges. 


A C-ben a globális konstansokat a fordító automatikusan extern elemekként kezeli, míg 


a Cs4-ban nem. Kötelező vagy kezdőértéket adni, vagy az extern kulcsszót használni 


(45.4.). 


A C-ben a beágyazott szerkezetek nevei ugyanabba a hatókörbe kerülnek, mint a felettük 
álló szerkezeté: 


struct S ( 
structT(/5...7] 
VE 

] 


struct T Xx; /t helyes C-ben, jelentése S::T x; ; Cx4-ban hibás 7 


A C-ben egy tömbnek olyan elemmel is adhatunk kezdőértéket, amelynek több eleme van, 
mint amennyire a deklarált tömbnek szüksége van: 


char v[5] — "Oscar"; /t helyes C-ben, a lezáró 0-t nem használja; C34-ban hibás 7 
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B.2.3. Elavult szolgáltatások 


Ha a szabványosító bizottság egy szolgáltatást elavultnak nyilvánít, akkor ezzel azt fejezi ki, 
hogy a szolgáltatást el kell kerülni. A bizottságnak azonban nincs joga egy korábban gyak- 
ran használható lehetőséget teljesen megszüntetni, akkor sem, ha az esetleg felesleges vagy 
kifejezetten veszélyes. Tehát az ,elavultság" kimondása csak egy (nyomatékos) ajánlás 
a programozóknak arra, hogy ne használják a lehetőséget. 


A static kulcsszó, melynek alapjelentése: , statikusan lefoglalt", általában azt jelzi, hogy egy 
függvény vagy egy objektum helyinek Cokálisnak) számít a fordítási egységre nézve: 


// fájl1: 
static int glob; 


// fájl2: 
static int glob; 


Ennek a programnak valójában két g/ob nevű, egész típusú változója lesz. Mindkettőt kizá- 
rólag azok a függvények fogják használni, amelyekkel megegyező fordítási egységben 
szerepel. 


A static kulcsszó használata a , lokális a fordítási egységre nézve"? értelemben elavult a Ct-- 
ban. Helyettük a névtelen névterek használata javasolt (48.2.5.19. 


A karakterlánc-literálok automatikus átalakítása (nem konstans) char" típusra szintén el- 
avult. Használjunk inkább névvel rendelkező karaktertömböket, így elkerülhetjük, hogy 
karakterlánc-literálokat kelljen értékül adnunk char" változóknak (§5.2.29. 


A C stílusú típusátalakítást az új átalakításoknak szintén elavulttá kellett volna tenniük; saj- 
nos még sokan használják, pedig a felhasználónak programjaiban érdemes komolyan meg- 
fogadnia a C stílusú átalakítások tilalmát. Ha explicit típusátalakításra van szükségünk, 
a static cast, a reinterpret cast, illetve a const cast kulcsszóval vagy ezek együttes haszná- 
latával ugyanazt az eredményt érhetjük el, mint a C stílusú átalakítással. Az új átalakításokat 
azért is érdemes használnunk, mert ezek szélesebb körben használhatók és pontosabban 
megfogalmazottak (§6.2.7). 
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B.2.4. Ct- -- program, ami nem C program 


Ebben a pontban azokat a szolgáltatásokat soroljuk fel, melyek a C---ban megtalálhatók, 
de a C-ben nem. A lehetőségeket szerepük szerint soroljuk fel. Természetesen számtalan 
osztályozás lehetséges, mert a legtöbb szolgáltatás több célt is szolgál, tehát az itt bemuta- 
tott nem az egyetlen jó csoportosítás: 


4 Lehetőségek, melyek elsősorban kényelmes jelölésrendszert biztosítanak: 
1. A / megjegyzések (§2.39; a C-ben is szerepelni fognak. 
2. Korlátozott karakterkészletek használatának lehetősége (4C.3.1. 
3. Bővített karakterkészletek használatának lehetősége (4C.3.3), a C-ben is 
megjelenik. 
4. A static tárban levő objektumok nem-konstans kezdőértéket is kaphatnak 
(49.4.1. 
A const a konstans kifejezésekben (§5.4, 4C.59. 
A deklarációk utasításokként szerepelnek. 
7. Deklarációk szerepelhetnek a for utasítás kezdőérték-adó elemében és az if 
feltételben is (46.3.3, §6.3.2.1. 
8. Az adatszerkezetek nevei előtt nem kell szerepelnie a struct kulcsszónak. 


SZA 


46 Lehetőségek, melyek elsősorban a típusrendszer erősítését szolgálják: 
1. A függvényparaméterek típusellenőrzése (§7.19; később a C-ben is megjelent 
(§B.2.2). 
2. Típusbiztos összeszerkesztés (49.2, 949.2.3). 
3. A szabad tár kezelése a new és a delete operátor segítségével (46.2.6, §10.4.5, 
§15.09. 
4. A const(§5.4, §5.4.1); később a C-be is bekerült. 
A logikai bool adattípus (44.2). 
6. Új típusátalakítási forma (46.2.7). 


s 


4 Felhasználói típusokat segítő lehetőségek: 

Osztályok (10. fejeze0. 

Tagfüggvények (410.2.1) és tagosztályok (§11.129. 

Konstruktorok és destruktorok (410.2.3, $10.4.1). 

Származtatott osztályok (12. fejezet, 15. fejezet). 

Virtuális függvények és elvont osztályok (§412.2.6, §12.3). 

A publicprotected/private hozzáférés-szabályozás (410.2.2, §15.3, 9C.11. 
A , barátok" (friend) lehetőségei (411.59. 

Mutatók tagokra (§15.5, $C.12). 

static tagok (§10.2.4). 


oz DOIT ON NP z9 ÉS AE 
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10. mutable tagok (§10.2.7.2). 
11. Operátor-túlterhelés (11. fejeze0. 
12. Hivatkozások (§5.5). 


4 Lehetőségek, melyek elsősorban a program rendszerezésére szolgálnak (az osz- 
tályokon túD: 

. Sablonok (13. fejezet, $C.13). 

. Helyben kifejtett (inline) függvények (§7.1.1. 

. Alapértelmezett paraméterek (§7.5). 

Függvénynév-túlterhelés (§7.4. 

. Névterek (48.29. 

.  Explicit hatókör-meghatározás (a :: operátor, 44.9.4). 

. Kivételkezelés (48.3, 14. fejezeD. 

. Futási idejű típus-meghatározás (415.4). 


A C44-ban bevezetett új kulcsszavak (§B.2.2) a legtöbb olyan szolgáltatást bemutatják, me- 
lyek kifejezetten a C$t4-ban jelentek meg. Van azonban néhány nyelvi elem — például 
a függvény-túlterhelés vagy a consts alkalmazása konstans kifejezésekben -, melyeket nem 
új kulcsszó segítségével valósít meg a nyelv. Az itt felsorolt nyelvi lehetőségek mellett a C4- 
könyvtár is (416.1.2) nagy részben csak a C----ra jellemző. 


A — cplusplus makró segítségével mindig megállapíthatjuk, hogy programunkat éppen C 
vagy Cst fordítóval dolgozzuk-e fel (49.2.4. 


B.3. Régebbi C-t ---változatok használata 


A C44 nyelvet 1983 óta folyamatosan használják (41.49). Azóta számtalan változat és önálló 
fejlesztőkörnyezet készült belőle. A szabványosítás alapvető célja, hogy a programozók és 
felhasználók részére egy egységes C--- álljon rendelkezésre. Amíg azonban a szabvány tel- 
jes körben el nem terjed a C---rendszerek készítői körében, mindig figyelembe kell ven- 
nünk azt a tényt, hogy nem minden megvalósítás nyújtja az összes szolgáltatást, ami ebben 
a könyvben szerepel. 


Sajnos nem ritka, hogy a programozók első komoly benyomásaikat a C-tt-ról egy négy-öt 
éves változat alapján szerzik meg. Ennek oka az, hogy ezek széles körben és olcsón elér- 
hetők. Ha azonban a legkisebb lehetősége is van, egy magára valamit is adó szakember 
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ilyen antik rendszernek a közelébe sem megy. Egy kezdőnek a régebbi változatok számta- 
lan rejtett problémát okozhatnak. A nyelvi lehetőségek és a könyvtárban megvalósított szol- 
gáltatások hiánya olyan problémák kezelését teszi szükségessé, melyek az újabb változa- 
tokban már nem jelentkeznek. A kevés lehetőséget biztosító régebbi változatok a kezdő 
programozó programozási stílusának is sokat ártanak, ráadásul helytelen képünk alakul ki 
arról, mi is valójában a C4-4. Véleményem szerint a C4- első megismerésekor nem az a leg- 
megfelelőbb részhalmaz, amely az alacsonyszintű szolgáltatásokat tartalmazza (tehát sem- 
miképpen sem a C és a C4t4 közös része). Azt ajánlom, először a standard könyvtárat és 
a sablonokat ismerjük meg, mert ezekkel egyszerűen megoldhatunk komolyabb feladato- 
kat is és jó ízelítőt kapunk a , valódi C-t" szolgáltatásaiból. 


A Cs első kereskedelmi kiadása 1985-ben jelent meg; e könyv első kiadása alapján készí- 
tették. Akkor a Cst még nem biztosított többszörös öröklődést, sablonokat, futási idejű tí- 
pusinformációkat, kivételeket és névtereket sem. Mai szemmel semmi értelmét nem látom 
annak, hogy olyan rendszerrel kezdjünk el dolgozni, amely ezen szolgáltatások legalább 
egy részét nem biztosítja. A többszörös öröklődés, a sablonok és a kivételek 1989-ben ke- 
rültek be a Ct-4-ba. A sablonok és kivételek első megvalósítása még nagyon kiforratlan és 
szegényes volt. Ha ezek használatakor problémákba ütközünk, sürgősen szerezzünk be 
egy újabb nyelvi változatot. 


Általában igaz, hogy olyan változatot érdemes használnunk, amely minden lehetséges he- 
lyen igazodik a szabványhoz, hogy elkerülhessük a megvalósításból eredő különbségeket, 
illetve az adott nyelvi változatnak a szabvány által nem meghatározott tulajdonságait. Ter- 
vezzük programjainkat úgy, mintha a teljes nyelv a rendelkezésünkre állna, majd valósítsuk 
meg önállóan a hiányzó részletek szolgáltatásait. Így jobban rendszerezett és könnyebben 
továbbfejleszthető programot kapunk, mint ha a Ct- mindenhol megtalálható, közös mag- 
jához terveznénk a programot. Arra is mindig figyeljünk, hogy megvalósítás-függő szolgál- 
tatásokat csak akkor használjunk, ha elkerülhetetlen. 


B.3.1. Fejállományok 


Eredetileg minden fejállomány kiterjesztése ./z volt, így a Ct- egyes változataiban is megje- 
lentek az olyan fejállományok, mint a cmap.h: vagy az Ciostream.h:. A kompatibilitás ér- 
dekében ezek általában ma is használhatók. 


Amikor a szabványosító bizottságnak új fejállományokat kellett bevezetnie a szabványos 
könyvtárak átírt változatai, illetve az újonnan meghatározott könyvtári szolgáltatások keze- 
léséhez, a fejállományok elnevezése problémákba ütközött. A régi ./z kiterjesztés használa- 
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ta összeegyeztethetőségi problémákat okozott volna. A megoldást a .7 kiterjesztés elhagyá- 
sa jelentette az új szabványos fejállomány-nevekben. Az utótag egyébként is felesleges volt, 
mert a £ 5 enélkül is jelezte, hogy szabványos fejállományt neveztünk meg. 


Tehát a standard könyvtár kiterjesztés nélküli fejállományokat biztosít (például cmap: vagy 
Ziostream5). Ezen állományok deklarációi az std névtérben szerepelnek. A régebbi fejállo- 
mányok a globális névtérben kapnak helyet és ezek nevében szerepel a ./7 kiterjesztés. 


Például: 


fincludeziostream: 


int mainŐ 
( 
std::cout 2£ "Helló, világNm"; 


J 


Ha ezt a programrészletet nem sikerül lefordítanunk, próbálkozzunk a hagyományosabb 
változattal: 


fincludeziostream.h: 


int mainŐ 
( 
cout 2 "Helló, világ Nm"; 


J 


A legtöbb hordozhatósági problémát a nem teljesen összeegyeztethető fejállományok 
okozzák. A szabványos fejállományok ebből a szempontból ritkábban jelentenek gondot. 
Nagyobb programoknál gyakran előfordul, hogy sok fejállományt használunk, és ezek nem 
mindegyike szerepel az összes rendszerben vagy sok deklaráció nem ugyanabban a fejál- 
lományban jelenik meg. Az is előfordul, hogy bizonyos deklarációk szabványosnak tűnnek 
(mert szabványos nevű fejállományokban szerepelnek), de valójában semmilyen szabvány- 
ban nem szerepelnek. 


Sajnos nincs teljesen kielégítő módszer a fejállományok által okozott hordozhatósági prob- 
lémák kezelésére. Egy gyakran alkalmazott megoldás, hogy elkerüljük a fejállományoktól 
való közvetlen függést és a fennmaradó függőségeket külön fogalmazzuk meg. Így a hor- 
dozhatóságot a közvetett hivatkozásokkal és az elkülönített függőségkezeléssel javítjuk. 


Például, ha egy szükséges deklaráció a különböző rendszerekben különböző fejállományo- 
kon keresztül érhető el, egy alkalmazásfüggő fejállományt használhatunk, amely az 
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finclude segítségével magába foglalja az egyes rendszerek megfelelő állományait. Ugyan- 
így, ha valamilyen szolgáltatást a különböző rendszerekben másképpen érhetünk el, a szol- 
gáltatáshoz alkalmazásfüggő osztályokat és függvényeket készíthetünk. 


B.3.2. A standard könyvtár 


Természetesen a Ct4 szabvány előtti változataiból hiányozhatnak a standard könyvtár bi- 
zonyos részei. A legtöbb rendszerben szerepelnek az adatfolyamok, a complex adattípus 
(általában nem sablonkénpD, a különböző string osztályok és a C standard könyvtára. 
A map, a list, a valarray stb. azonban gyakran hiányozik ezekből a megvalósításokból. 
Ilyenkor próbáljuk az elérhető könyvtárakat úgy használni, hogy később lehetőségünk le- 
gyen az átalakításra, ha szabványos környezetbe kerülünk. Általában jobban járunk, ha 
a nem szabványos string, list vagy map osztályt használjuk, ahelyett, hogy a standard 
könyvtár osztályainak hiánya miatt visszatérnénk a C stílusú programozáshoz. Egy másik le- 
hetőség, hogy a standard könyvtár STL részének (16., 17., 18. és 19. fejezet) jó megvalósí- 
tásai tölthetők le ingyenesen az Internetről. 


A standard könyvtár régebbi változatai még nem voltak teljesek. Például sokszor jelentek 
meg tárolók úgy, hogy memóriafoglalók használatára még nem volt lehetőség, vagy éppen 
ellenkezőleg, mindig kötelező volt megadni a memóriafoglalót. Hasonló problémák fordul- 
tak elő az , eljárásmód-paraméterek" esetében is, például az összehasonlítási feltételeknél: 


listzint: li; // rendben, de néhány megvalósítás megköveteli a memóriafoglalót 
listzint, allocatorsint: : li2; // rendben, de néhány megvalósítás nem ismeri 
// a memóriafoglalót 


mapsstring, Record: m1I; // rendben, de néhány megvalósítás megkövetel egy 
// kisebb mint" műveletet 
mapsstring, Record, lesssstring2: 2 m2; 


Mindig azt a változatot kell használnunk, amelyet az adott fejlesztőkörnyezet elfogad. Sze- 
rencsés esetben rendszerünk az összes formát ismeri. 


A régebbi C-t--változatokban gyakran istrstream és ostrstream osztály szerepelt, 
a Cstrstream.h: nevű fejállomány részeként, míg a szabvány az istringstream és 
ostringstream osztályokat adja meg, melyeknek helye az csstream: fejállomány. 
A strstream adatfolyamok közvetlenül karaktertömbökön végeztek műveleteket (lásd 
§21.10 [26D. 
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A szabvány előtti C4--változatokban az adatfolyamok nem voltak paraméteresek. A basic 
előtagú sablonok újak a szabványban; a basic ios osztályt régebben ios osztálynak hívták. 
Kissé meglepő módon az iostate régi neve viszont io state volt. 


B.3.3. Névterek 


Ha rendszerünk nem támogatja a névterek használatát, a program logikai szerkezetét kife- 
jezhetjük forrásfájlok segítségével is (9.fejezet). A fejállományok ugyanígy jól használhatók 
saját vagy C kóddal közösen használt felületeink leírására. 


Ha a névterek nem állnak rendelkezésre, a névtelen névterek hiányát a static kulcsszó hasz- 
nálatával ellensúlyozhatjuk. Szintén sokat segíthet, ha a globális nevekben egy előtaggal je- 


lezzük, hogy milyen logikai egységhez tartoznak: 


// névtér előtti nyelvi változatokban: 


class bs string f/5... 7 // Bjarne saját string típusa 
typedef int bs bool; // Bjarne saját bool típusa 
class joe string; // Joe saját string típusa 


enum joe boolt joe false, joe true]l; — // Joe saját bool típusa 


Az előtagok kiválasztásakor azonban legyünk elővigyázatosak, mert a létező C és Ct-t 
könyvtárak esetleg ugyanilyen előtagokat használnak. 


B.3.4. Helyfoglalási hibák 


Mielőtt a kivételkezelés megjelent a C--4t-ban, a new operátor 0 értéket adott vissza, ha 
a helyfoglalás nem sikerült. A szabványos C-t new operátora ma már egy bad alloc kivé- 
tellel jelzi a hibát. 


Általában érdemes programjainkat a szabványnak megfelelően átírni. Itt ez annyit jelent, 
hogy nem a O visszatérési értéket, hanem a bad alloc kivételt figyeljük. Általában mindkét 
esetben nagyon nehéz a problémát egy hibaüzenetnél hatékonyabban kezelni. 


Ha úgy érezzük, nem érdemes a O érték vizsgálatát a bad alloc kivétel figyelésére átalakí- 
tani, általában elérhetjük, hogy a program úgy működjön, mintha nem állnának rendelke- 
zésünkre a kivételek. Ha rendszerünkben nincs new handler telepítve, a nothrow memó- 
riafoglaló segítségével kivételek helyett a 0O visszatérési értékkel vizsgálhatjuk 
a helyfoglalási hibák előfordulását: 
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X"p1- new X; // bad alloc kivételt vált ki, ha nincs memória 


X"p2 - neu(mothrow) X; // visszatérési értéke O, ha nincs memória 


B.3.5. Sablonok 


A szabvány számos új szolgáltatást vezetett be a sablonok körében és a régebbi lehetősé- 
gek szabályait is tisztábban fogalmazta meg. 


Ha rendszerünk nem támogatja a részlegesen egyedi célú változatok (specializációk) meg- 
adását, akkor azokhoz a sablonokhoz, amelyeket egyébként egyszerű szakosítással hoz- 
nánk létre, önálló nevet kell rendelnünk: 


templatexclass T- class plist : private listzvoid"? ( // listzT" kellett volna 
Meg 
] 


Ha az adott nyelvi változat nem támogatja a sablon tagok használatát, néhány módszerről 
kénytelenek leszünk lemondani. A sablon tagok segítségével például olyan rugalmasan ha- 
tározhatjuk meg elemek létrehozását, illetve átalakítását, amire ezek nélkül nincs lehetősé- 
günk. (413.6.2.) Néha kisegítő megoldást jelent az, hogy egy önálló (nem tag) függvényt 
adunk meg, amely létrehozza a megfelelő objektumot: 


templatexclass T- class X ( 

Haz 

templatexclass Az X(const AG a); 
FA 


Ha nem használhatunk sablon tagokat, kénytelenek vagyunk konkrét típusokra korlátozni 
tevékenységünket: 


templatexciass T- class X (f 
Ia 
X(const A16 a); 
X(const A26 a); 
VAA 
FA 


A korábbi C---rendszerek többsége a sablon osztályok példányosításakor a sablon összes 
függvényét lemásolja és létrehozza kódjukat. Ez ahhoz vezethet, hogy a nem használt tag- 
függvények hibát okoznak (4C.13.9.1.). A megoldást az jelenti, ha a kérdéses tagfüggvények 
meghatározását az osztályon kívül helyezzük el. 
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templatexclass T- class Container ( 
ST 
public: 
void sortO ( /" használja 2 műveletet "/ ) // osztályon belüli meghatározás 


jj: 
class Glob ( /" a Glob-ban nincs £ művelet ? ]; 


ContainerZGlob: cg; // néhány szabvány előtti változatban 
// ContainerZGlob:::sortO) szerepel 


helyett például a következő megoldást adhatjuk: 


templatexcilass T: class Container ( 
Ma 

bublic: 
void sort; 

]: 


templatexclass T- void ContainerzT2::sort0 ( /" a c művelet használata 7) 
// osztályon kívüli definició 


class Glob ( /" a Glob-ban nincs £ művelet 7 ]; 


ContainerZGlob: cg; // nincs baj, amíg a cg.sortO-ot meg nem hívjuk 


A C34 régebbi megvalósításai nem teszik lehetővé az osztályban később bevezetett tagok 
kezelését: 


templatexclass T- class Vector (f 

bublic: 
I6 operatorl[(size ti) ( return ulil; ) / v később bevezetendő 
8 

Private: 
T" u; // hoppá: nem találja! 
size tsz; 


J; 


Ilyenkor vagy úgy rendezzük át a tagokat, hogy elkerüljük az ilyen problémákat, vagy 
a függvény meghatározását az osztálydeklaráció után helyezzük. 
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Néhány, szabvány előtti C-H---változat a sablonok esetében nem fogadja el az alapértelme- 
zett paraméterek használatát (413.4.1.). Ez esetben minden sablonparamétert külön meg 
kell adnunk: 


templatecciass Key, class T; class LT - lesszT- : class map (f 


17 aaz 
fa 
mapsstring, int: m; // hoppá: nem lehet alapértelmezett sablonbaraméter 
mapc string, int, lesszstring: 2 m2; // megoldás: explicit megadás 


[dc 


B.3.6. A for utasítás kezdőérték-adó része 
Vizsgáljuk meg az alábbi példát: 


void f(vectorcchar:€6 v, int m) 
t 


for (int i- O; iZv.size0) SG iz-m; 4-1) cout cz ulil; 


if G -—- m) ( // hiba: hivatkozás i-re a for! utasítás után 
EY 
J 
J 


Az ilyen programok régebben működtek, mert az eredeti C----ban a változó hatóköre a for 
utasítást tartalmazó hatókör végéig terjedt. Ha ilyen programokkal találkozunk, a változót 
érdemes egyszerűen a /or ciklus előtt bevezetnünk: 


void fXvectorcchar-G vu, int m) 

t 
int i- O; // 4 kell a ciklus után 
for G izv.size0) 66 iSzm; 441) cout CZ ulij; 


if G -—— m) ( 
EK 
J 
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B.4. Tanácsok 


[1] 


[2] 


[3] 


[4] 


[5] 


[6] 


[7] 


[8] 


[91 


[10] 


[11] 


[12] 


A C4t4 megtanulásához használjuk a szabványos C--- legújabb és legteljesebb 
változatát, amihez csak hozzá tudunk férni. §B.3. 

A C és a Cs közös része egyáltalán nem az a része a C4-4-nak, amit először 
meg kell tanulnunk. §1.6, §B.3. 

Amikor komoly alkalmazást készítünk, gondoljunk rá, hogy nem minden C--t- 
változat tartalmazza a szabvány összes lehetőségét. Mielőtt egy főbb szolgálta- 
tást használunk egy komoly programban, érdemes kitapasztalnunk azt egy-két 
kisebb program megírásával. Ezzel ellenőrizhetjük, hogy rendszerünk mennyire 
illeszkedik a szabványhoz és mennyire hatékony a megvalósítás. Példaképpen 
lásd §8.5[6-71, §16.5[10], §B.5[71 

Kerüljük az elavult szolgáltatásokat, például a static kulcsszó globális használa- 
tát, vagy a C stílusú típusátalakítást. 

A szabvány megtiltotta az , implicit int? használatát, tehát mindig pontosan ad- 
juk meg függvényeink, változóink, konstansaink stb. típusát. §B.2.2. 

Amikor egy C programot C-t programmá alakítunk, először a függvénydeklará- 
ciókat (prototípusokat), és a szabványos fejállományok következetes használa- 
tát ellenőrizzük. §B.2.2. 

Amikor egy C programot C-4-4 programmá alakítunk, nevezzük át azokat a válto- 
zókat, melyek C-t- kulcsszavak. §B.2.2. 

Amikor egy C programot C-4- programmá alakítunk, a mallocO) eredményét 
mindig megfelelő típusúra kell alakítanunk. Még hasznosabb, ha a mallocO 
összes hívását a new operátorral helyettesítjük. §B.2.2. 

Ha a mallocO és a freeO függvényeket a new és a delete operátorra cseréljük, 
vizsgáljuk meg, hogy a reallocO függvény használata helyett nem tudjuk-e 

a vector, a bush backO és a reserveO szolgáltatásait igénybe venni. §3.8, §16.3.5. 
Amikor egy C programot C-4- programmá alakítunk, gondoljunk rá, hogy nincs 
automatikus átalakítás egészekről felsoroló típusokra, tehát meghatározott átala- 
kítást kell alkalmaznunk, ha ilyen átalakításra van szükség. §4.8. 

Az std névtérben meghatározott szolgáltatások kiterjesztés nélküli fejállomá- 
nyokban szerepelnek. (Az std::cout deklarációja például az Ciostream? fejállo- 
mány része.) A régebbi változatokban a standard könyvtár nevei is a globális 
névtérbe kerültek, a fejállományok pedig .7 kiterjesztéssel rendelkeztek. 

(A ::cout deklarációja például az Ciostream.h: fejállományban szerepelt.) §9.2.2, 
$B.3.1. 

Ha régebbi C-- programok a new visszatérési értékét a 0 értékkel hasonlítják 
össze, akkor ezt a bad alloc kivétel ellenőrzésére kell cserélnünk, vagy 

a neuw(nothrow) utasítást kell helyette használnunk. §B.3.4. 
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[13] 


[14] 


[15] 


[16] 


[17] 


[18] 
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Ha fejlesztőkörnyezetünk nem támogatja az alapértelmezett sablonparaméterek 
használatát, meg kell adnunk minden paramétert. A tybedef segítségével a sab- 
lonparaméterek ismételgetése elkerülhető (ahhoz hasonlóan, ahogy a string tí- 
pus-meghatározás megkímél minket a basic string£ char, char. traitsZchar7", 
allocatoráKchar: : leírásától). §B.3.5. 

Az std::string osztály használatához a cstring: fejállományra van szükségünk. 
(A cstring.h: állományban a régi, C stílusú karakterlánc-függvények szerepel- 
nek.) §9.2.2, §B.3.1. 

Minden cX.h: szabványos C fejállománynak (amely a globális névtérbe vezet 
be neveket) megfelel egy ccX- fejállomány, amely az elemeket az sid névtérbe 
helyezi. §B.3.1. 

Nagyon sok rendszerben található egy "Szring.h" fejállomány, amely egy karak- 
terlánc-típust ír le. Mindig gondoljunk rá, hogy ezek eltérhetnek a szabványos 
string osztálytól. 

Ha lehetőségünk van rá, a szabványos eszközöket használjuk a nem szabvá- 
nyos lehetőségek helyett. §20.1, §B.3, 9C.2. 

Ha C függvényeket vezetünk be, használjuk az extern "C" formát. 


B.5. Gyakorlatok 


1. 


(C2.5) Vegyünk egy C programct és alakítsuk át C---ra. Soroljuk fel a program- 
ban használt, a Ct4t-ban nem használható elemeket, és vizsgáljuk meg, érvénye- 
sek-e az ANSI C szabvány szerint. Első lépésben a programot csak ANSI C for- 
mátumra alakítsuk (prototípusokkal stb.), csak ezután C4--ra. Becsüljük meg, 
mennyi időt vesz igénybe egy 100 000 soros C program átalakítása C-4--ra. 


. (2.5) Írjunk programot, amely segít átalakítani egy C programot C-ra. Végez- 


Ze el azon változók átnevezését, melyek a C--4-ban kulcsszavak, a mallocO hí- 
vásokat helyettesítse a new operátorral stb. Ajánlás: ne akarjunk tökéletes prog- 
ramot írni. 


. €2) Egy C stílusú C4-4 programban (például amit mostanában alakítottak át egy 


C programból) a mallocO függvény hívásait cseréljük a new operátor meghívá- 
sára. Ötlet: §B.4[8-9] 


. 2.5) Egy C stílusú Cst programban (például amit mostanában alakítottak át 


egy C programból a makrók, globális változók, kezdőérték nélküli változók és 
típusátalakítások számát csökkentsük a minimumra. 
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. C€3) Vegyünk egy C-t programot, amit egy egyszerű eljárással alakítottunk át egy 
C programból, és bíráljuk azt, mint C-t programot az adatrejtés, az elvont ábrá- 
zolás, az olvashatóság, a bővíthetőség és a részek esetleges újrahasznosíthatósá- 
ga szerint. Végezzünk valamilyen nagyobb átalakítást ezen bírálatok alapján. 

. C2) Vegyünk egy kicsi (mondjuk 500 soros) Ct-4 programot és alakítsuk azt C 
programmá. Hasonlítsuk össze a két programot a méret és az elképzelhető to- 
vábbfejlesztések szempontjából. 

. C3) Írjunk néhány kicsi tesztprogramot, mellyel megállapíthatjuk, hogy egy 
C4-4-változat rendelkezik-e a legújabb szabványos lehetőségekkel. Például mi 
a for utasítás kezdőérték-adó részében bevezetett változó hatóköre? (Y§B.3.6.) 
Használhatók-e alapértelmezett sablonparaméterek? (4B.3.5.) Használhatók-e 
sablon tagok? (48.2.6.) Ajánlás: §B.2.4. 

. (€2.5) Vegyünk egy C4t-4 programot, amely egy cX.h: fejállományt használ és 
alakítsuk át úgy, hogy az CX- és ccX- fejállományokat használja. Csökkentsük 
a lehető legkevesebbre a using utasítások használatát. 


Technikai részletek 


, Valahol a lélek és az Univer- 
zum legmélyén mindennek 
megvan a maga oka" 
(Slartibartfast) 


Mit ígér a szabvány? e Karakterkészletek e Egész literálok 9 Konstans kifejezések — Kiter- 
jesztések és átalakítások e Többdimenziós tömbök s Mezők és uniók 9 Memóriakezelés s 
Szemétgyűjtés s Névterek e Hozzáférés-szabályozás s Mutatók adattagokra e Sablonok e 
static tagok e friend-ek s Sablonok, mint sablonparaméterek s Sablonparaméterek leveze- 
tése e A typename és a template minősítők s Példányosítás s Névkötés e Sablonok és név- 
terek e Explicit példányosítás s Tanácsok 


C.1. Bevezetés és áttekintés 


Ebben a fejezetben olyan technikai részleteket és példákat mutatok be, amelyeket nem le- 
hetett elegánsan beilleszteni abba a szerkezetbe, amit a C-t nyelv főbb lehetőségeinek be- 
mutatására használtam. Az itt közölt részletek fontosak lehetnek programjaink megírásakor 
is, de elengedhetetlenek, ha ezek felhasználásával készült programot kell megértenünk. 
Technikai részletekről beszélek, mert nem szabad, hogy a tanulók figyelmét elvonja az el- 
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sődleges feladatról, a Ct- nyelv helyes használatának megismeréséről, vagy hogy a prog- 
ramozókat eltérítse a legfontosabb céltól, gondolataik olyan tiszta és közvetlen megfogal- 


mazásától, amennyire csak a Ct4-- lehetővé teszi. 


C.2. A szabvány 


Az általános hiedelemmel ellentétben a feltétlen ragaszkodás a Ct-4 nyelvhez és a szabvá- 
nyos könyvtárakhoz önmagában véve nem jelent sem tökéletes programot, sem hordozha- 
tó kódot. A szabvány nem mondja meg, hogy egy programrészlet jó vagy rossz, mindössze 
azt árulja el, hogy a programozó mit várhat el egy megvalósítástól és mit nem. Van, aki 
a szabvány betartásával is borzalmas programokat ír, míg a legtöbb jó program használ 
olyan lehetőségeket is, melyeket a szabvány nem tartalmaz. 


A szabvány nagyon sok fontos dolgot megvalósítás-függőnek (implementation-defined) mi- 


nősít. Ez azt jelenti, hogy minden nyelvi változatnak egy konkrét, pontosan meghatározott 
megoldást kell adnia az adott kérdésre és ezt a megoldást pontosan dokumentálnia is kell: 


unsigned char c1 - 64; // megfelelő meghatározás: egy karakter legalább 8 bit és 
// mindig képes 64-et tárolni 
unsigned char c2- 1256; — // megvalósítás-függő: csonkol, ha a char csak 8 bites 


A c! kezdeti értékadása megfelelően meghatározott, mert a chartípusnak legalább 8 bites- 
nek kell lennie, a c2-é viszont megvalósítás-függő, mert a char típus ábrázolásához hasz- 
nált bitek pontos száma is az. Ha a char csak 8 bites, az 1256 érték 232-re csonkul 
(4C.6.2.19. A legtöbb megvalósítás-függő szolgáltatás a programok futtatásához használt 
hardverhez igazodik. 


Amikor komoly programokat írunk, gyakran szükség van arra, hogy megvalósítás-függő le- 
hetőségeket használjunk. Ez az ára annak, ha számtalan különböző rendszeren hatékonyan 
futtatható programokat akarunk írni. Sokat egyszerűsített volna a nyelven, ha a karaktere- 
ket 8 bitesként, az egészeket pedig 32 bitesként határozzuk meg. Nem ritkák azonban a 16 
vagy 32 bites karakterkészletek, sem az olyan egész értékek, melyek nem ábrázolhatók 32 
biten. Ma már léteznek 32 gigabájtot meghaladó kapacitású merevlemezek is, így a lemez- 
címek ábrázolásához érdemes lehet 48 vagy 64 bites egész értékeket használni. 
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A hordozhatóság lehető leghatékonyabb megvalósításához érdemes pontosan megfogal- 
maznunk, hogy milyen megvalósítás-függő nyelvi elemeket használtunk a programunkban, 
és érdemes világosan elkülönítenünk a program azon részeit, ahol ezeket a szolgáltatáso- 
kat használjuk. Egy jellemző példa erre a megoldásra, hogy az összes olyan elemet, amely 
valamilyen módon függ a hardvertől, egy fejállományban, konstansok és típus-meghatáro- 
zások formájában rögzítjük. Ezt az eljárást támogatja a standard könyvtár a numeric limits 
osztállyal (422.2). 


A nem meghatározott (definiálatlan) viselkedés kellemetlenebb dolog. Egy nyelvi szerkeze- 
tet akkor nevez nem meghatározottnak a szabvány, ha semmilyen értelmes működést nem 
várhatunk el a megvalósítástól. A szokásos megvalósítási módszerek általában a nem meg- 
határozott lehetőségeket használó programok nagyon rossz viselkedését eredményezik: 


const int size — 471024; 
char pagelsizel; 


void JO 
t 
bagelsizetsizel — 7; // nem meghatározható 


J 


Egy ilyen programrészlet teljesen kézenfekvő következménye, hogy a memóriában olyan 
adatokat írunk felül, melyeket nem lenne szabad, vagy hardverhibák, kivételek lépnek fel. 
A megvalósítástól nem várhatjuk el, hogy ilyen kézenfekvő szabálytalanság esetében is 
ésszerűen működjön. Ha a programot komolyan optimalizáljuk, a nem meghatározott szer- 
kezetek használatának eredménye teljesen kiszámíthatatlanná válik. Ha létezik kézenfekvő 
és könnyen megvalósítható megoldása egy problémának, azt inkább megvalósítás-függő- 


nek minősíti a szabvány és nem definiálatlannak. 


Érdemes jelentős időt és erőfeszítést szánnunk annak biztosítására, hogy programunk sem- 
mi olyat ne használjon, ami a szabvány által nem meghatározott helyzetekhez vezethet. Sok 
esetben külön eszközök segítik ezt a munkát. 
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C.3. Karakterkészletek 


E könyv példaprogramjai az ASCII-nek (ANSI3.4-1968) nevezett, 7 bites, nemzetközi, ISO 
646-1983 karakterkészlet amerikai angol változatának felhasználásával készültek. Ez há- 
romféle problémát jelenthet azoknak, akik más karakterkészletet használó C--- 
környezetben írják programjaikat: 


1. Az ASCII tartalmaz olyan elválasztó karaktereket és szimbólumokat is — például 
a ], a ( vagy a ! —, melyek egyes karakterkészletekben nem találhatók meg. 

2. Azokhoz a karakterekhez, melyeknek nincs hagyományos ábrázolása, valami- 
lyen jelölésmódot kell választanunk (például az újsorhoz, vagy a 17-es kódú ka- 
rakterhez). 

3. Az ASCII nem tartalmaz bizonyos karaktereket — például a f, a II vagy az a —, 
melyeket az angoltól eltérő nyelvekben viszonylag gyakran használnak. 


C.3.1. Korlátozott karakterkészletek 
A különleges ASCII karakterek -— [, I, (, j, I! és V— az ISO szerint betűnek minősített karak- 
terpozíciót foglalnak el. A legtöbb európai ISO-646 karakterkészletben ezeken a pozíció- 
kon az angol ábécében nem szereplő betűk szerepelnek. A dán nemzeti karakterkészlet 
például ezeket a pozíciókat az /E, 2, Ó, o, Á, á magánhangzók ábrázolására használja és 
ezek nélkül nem túl sok dán szöveg írható le. 


A trigráf (három jelből álló) karakterek szolgálnak arra, hogy tetszőleges nemzeti karakte- 
reket írhassunk le, , hordozható" formában, a legkisebb szabványos karakterkészlet felhasz- 
nálásával. Ez a forma hasznos lehet, ha programunkat tényleg át kell vinnünk más rendszer- 
re, de a programok olvashatóságát ronthatja. Természetesen a hosszú távú megoldás erre 
a problémára a Ct4 programozók számára az, hogy beszereznek egy olyan rendszert, ahol 
saját nemzeti karaktereiket és a Ct- jeleit is használhatják. Sajnos ez a megoldás nem min- 
denhol megvalósítható, és egy új rendszer beszerzése idegesítően lassú megoldás lehet. 
A C44 az alábbi jelölésekkel teszi lehetővé, hogy a programozók hiányos karakterkészlet- 


tel is tudjanak programot írni: 


C. Technikai részletek 1119 




















Kulcsszavak Digráf Trigráf 

and 6.6 cz ( ??7 

and eg 6.7 55 ) ag 

bitand § c: [ ??a 

bitor ] 1 ] ??/ N 
compi a 8: ij 22) 

not ! $:$: tt ??5 ; 
or I] ESESEÉ 5 
or. eg ]- 22 

XOT íz Vára őz 
Xxor. eg 5z 

not eg Ez 














Azok a programok melyek ezeket a kulcsszavakat és digráf karaktereket használják, sokkal 
olvashatóbbak, mint a velük egyenértékű, de trigráf karakterekkel készült programok. Ha 
azonban az olyan karakterek, mint a ( nem érhetők el rendszerünkben, kénytelenek va- 
gyunk a trigráf karaktereket használni a karakterláncokban és karakter-konstansokban a hi- 
ányzó jelek helyett. A "helyett például a 77" karakterkonstanst írhatjuk. 


Egyes programozók hagyományos operátor-megfelelőik helyett szívesebben használják az 
and és hasonló kulcsszavakat. 
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C.3.2. Vezérlőkarakterek 


A V jel segítségével néhány olyan karaktert érhetünk el, melyeknek szabványos neve is van: 











Név ASCII jelölés C-H- jelölés 
újsor/sortörés NL CP wmn 
vízszintes tabulátor HT vt 
függőleges tabulátor VT VV 
visszatörlés BS vb 
kocsivissza CR Mis 
lapdobás FF v£ 
csengő BEL va 
fordított perjel AV VA 
kérdőjel ? N2 
aposztróf jé WE 
idézőjel jú Vé 
oktális szám 000 1000 
hexadecimális szám hhh vxhhh... 











Megjelenési formájuk ellenére ezek is egyetlen karaktert jelentenek. 


Lehetőségünk van arra is, hogy egy karaktert egy-, két- vagy háromjegyű, oktális (a V után 
nyolcas számrendszerbeli), vagy hexadecimális (a Mx után 16-os számrendszerbeli) szám- 
ként adjunk meg. A hexadecimális jegyek száma nem korlátozott. Az oktális vagy hexade- 
cimális számjegyek sorozatának végét az első olyan karakter jelzi, amely nem értelmezhe- 
tő oktális, illetve hexadecimális jegyként: 








Oktális Hexadecimális Decimális ASCII 
rve TNx6" 6 ACK 
rN60" ENS30 48 TO" 


"NAB "Sg0sE 95 dea 
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Ez a jelölés lehetővé teszi, hogy az adott rendszer tetszőleges karakterét leírjuk vagy karak- 
terláncokban felhasználjuk azokat (lásd §5.2.29. Viszont ha a karakterek jelölésére számo- 
kat használunk, programunk nem lesz átvihető más karakterkészletet használó rendszerre. 


Lehetőség van arra is, hogy egy karakterliterálban egynél több karaktert adjunk meg (pél- 
dául ab). Ez a megoldás azonban elavult és megvalósítás-függő, így érdemes elkerülnünk. 


Ha egy karakterláncban oktális konstansokat használunk a karakterek jelölésére, érdemes 
mindig három jegyet megadnunk. A jelölésrendszer elég kényelmetlen, így könnyen elté- 
veszthetjük, hogy a konstans utáni karakter számjegy-e vagy sem. A hexadecimális kons- 
tansok esetében használjunk két számjegyet: 


char v1(] - "aNxah129"; // 6 karakter: "a!" Nxa" h! N12" 99" NO! 
char v2/] - "avxah127; 5 karakter: a!" Nxa! h! N127 NO! 
char v3/] —- "avxad127; // 4 karakter: "a! Nxad" N127" NO! 
char vál] - "aNxadNo0127; 5 karakter: "a! Nxad" NO12! "7" NO! 


C.3.3. Nagy karakterkészletek 


C-t4 programot írhatunk olyan karakterkészletek felhasználásával is, melyek sokkal bőveb- 
bek, mint a 127 karakterből álló ASCII készlet. Ha az adott nyelvi változat támogatja a na- 
gyobb karakterkészleteket, az azonosítók, megjegyzések, karakter konstansok és karakter- 
láncok is tartalmazhatnak olyan karaktereket, mint az á, a B vagy a I. Ahhoz azonban, hogy 
az így készült program hordozható legyen, a fordítónak ezeket a különleges karaktereket 
valahogy olyan karakterekre kell , kódolnia", melyek minden C---változatban elérhetők. 
Ezt az átalakítást a Cst — a könyvben is használt — alap karakterkészletére a rendszer álta- 
lában még azelőtt végrehajtja, hogy a fordító bármilyen más tevékenységbe kezdene, tehát 
a programok jelentését ez nem érinti. 


A nagy karakterkészletekről a C-t által támogatott kisebb karakterkészletre való szabvá- 
nyos átalakítást négy vagy nyolc jegyből álló hexadecimális számok valósítják meg: 


általános karakternév: 
WXXXXXXXX 
Wu xXxXXxx 


Itt X egyetlen, hexadecimális számjegyet jelöl (például WwIe2b). A rövidebb MIXXXX jelö- 
lés egyenértékű a (WV0000XXXX-szel. Ha a megadott számban a jegyek száma nem négy és 
nem is nyolc, a fordító hibát jelez. 
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A programozó ezeket a karakterkódolásokat közvetlenül használhatja, de valójában arra ta- 
lálták ki, hogy a programozó által látható karaktereket a megvalósítás belsőleg egy kisebb 
karakterkészlettel tárolhassa. 

Ha a bővített karakterkészletek azonosítókban való használatához egy adott környezet 
egyedi szolgáltatásaira támaszkodunk, programunk hordozhatóságát erősen lerontjuk. Ha 
nem ismerjük azt a természetes nyelvet, amelyet az azonosítók, illetve megjegyzések meg- 
fogalmazásához használtak, a program nagyon nehezen olvasható lesz, ezért a nemzetkö- 
zileg használt programokban érdemes megmaradnunk az angol nyelvnél és az ASCII karak- 
terkészletnél. 


C.3.4. Előjeles és előjel nélküli karakterek 


Megvalósítás-függő az is, hogy az egyszerű cAar előjeles vagy előjel nélküli típus-e, ami né- 
hány kellemetlen meglepetést és váratlan helyzeteket eredményezhet: 


char c - 255; // a 255 "csupa egyes", hexadecimális jelöléssel OXFF 
inti — c; 


Mi lesz itt az i értéke? Sajnos nem meghatározható. A válasz az általam ismert összes nyelvi 
változatban attól függ, hogy a char érték bitmintája milyen értéket eredményez, ha egész- 
ként értelmezzük. Egy SGI Challenge gépen a char előjel nélküli, így az eredmény 255. Egy 
Sun SPARC vagy egy IBM PC gépen viszont a cAar előjeles, aminek következtében az i ér- 
téke -7 lesz. Ilyenkor a fordítónak illik figyelmeztetnie, hogy a 255 literál karakterré alakí- 
tásával a -] értéket kapjuk. A C-t nem ad általános megoldást ezen probléma kiküszöbö- 
lésére. Az egyik lehetőség, hogy teljesen elkerüljük az egyszerű char típus használatát és 
mindig valamelyik egyedi célú változatot használjuk. Sajnos a standard könyvtár bizonyos 
függvényei (például a stircempO) egyszerű char típusú paramétert várnak (420.4.1). 


Egy char értéknek mindenképpen signed char vagy unsigned char típusúnak kell lennie, 
de mind a három karaktertípus különböző, így például a különböző cAar típusokra hivat- 


kozó mutatók sem keverhetők össze: 


void (char c, signed char sc, unsigned char uc) 


( 
char" pc - €uc; // hiba: nincs mutató-átalakítás 
signed char"? psc — pc; // hiba: nincs mutató-átalakítás 
unsigned char" puc - pc; // hiba: nincs mutató-átalakítás 
bsc - puc; // hiba: nincs mutató-átalakítás 
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A különböző cAar típusok változói szabadon értékül adhatók egymásnak, de amikor egy 
előjeles char változóba túl nagy értéket akarunk írni, az eredmény nem meghatározható 
lesz: 


void (char c, signed char sc, unsigned char uc) 
t 


c - 255; // megvalósítás-függő, ha a sima karakterek előjelesek és 8 bitesek 


c-sc; — // rendben 

c- uc; — // megvalósítás-függő, ha a sima karakterek előjelesek és "uc! értéke túl nagy 

sc - uc; // megvalósítás-függő, ha "uc! értéke túl nagy 

uc- sc; // rendben: átalakítás előjel nélkülire 

sc-c; — // megvalósítás-függő, ha a sima karakterek előjel nélküliek és (c! értéke túl nagy 
uc-c;  // rendben: átalakítás előjel nélkülire 


Ha mindenhol az egyszerű char típust használjuk, ezek a problémák nem jelentkeznek. 


C.4. Az egész literálok típusa 


Az egész literálok típusa általában alakjuktól, értéküktől és utótagjuktól is függ: 


$ Ha decimális értékről van szó és a végére nem írunk semmilyen utótagot, típusa 
az első olyan lesz a következők közül, amelyben ábrázolható: int, long int, 
unsigned long int. 

46 Ha oktális vagy hexadecimális formában, utótag nélkül adjuk meg az értéket, 
annak típusa az első olyan lesz a következők közül, amelyben ábrázolható: int, 
unsigned int, long int, unsigned long int. 

6 Ha az u vagy az U utótagot használjuk, a típus a következő lista első olyan típu- 
sa lesz, amelyben az érték ábrázolható: unsigned int, unsigned long int. 

46 Hal/!/vagy L utótagot adunk meg, az érték típusa a következő lista első olyan tí- 
pusa lesz, amelyben az érték ábrázolható: long int, unsigned long int. 

6 Ha az utótag ul, lu, ul, Lu, UI, IU, UL vagy LU, az érték típusa unsigned long int 
lesz. 


A 100000 például egy olyan gépen, amelyen az int 32 bites, int típusú érték, de long int 
egy olyan gépen, ahol az int 16, a long int pedig 32 bites. Ugyanígy a OXAO00 típusa int, 
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ha az int 32 bites, de unsigned int, ha 16 bites. Ezeket a ,megvalósítás-függőségeket" az 
utótagok használatával kerülhetjük el: a 700000L£L minden gépen long int típusú, 
a 0XAO000U pedig minden gépen unsigned int. 


C.5. Konstans kifejezések 


Az olyan helyeken, mint a tömbhatárok (§5.2.), a case címkék (§6.3.2.) vagy a felsoroló ele- 
mek kezdőérték-adói (44.8.), a Ct-4 konstans kifejezéseket használ. A konstans kifejezés ér- 
téke egy szám vagy egy felsorolási konstans. Ilyen kifejezéseket literálokból (44.3.1, §4.4.1, 
§4.5.1), felsoroló elemekből (44.8) és konstans kifejezésekkel meghatározott const értékek- 
ból építhetünk fel. Sablonokban egész típusú sablonparamétereket is használhatunk 
(4C.13.39. Lebegőpontos literálok (§44.5.1) csak akkor használhatók, ha azokat meghatáro- 
zott módon egész típusra alakítjuk. Függvényeket, osztálypéldányokat, mutatókat és hivat- 
kozásokat csak a sizeof operátor (§6.2) paramétereként használhatunk. 


A konstans kifejezés egy olyan egyszerű kifejezés, melyet a fordító ki tud értékelni, mielőtt 
a programot összeszerkesztenénk és futtatnánk. 


C.6. Automatikus típusátalakítás 


Az egész és a lebegőpontos típusok (§4.1.1) szabadon keverhetők az értékadásokban és 
a kifejezésekben. Ha lehetőség van rá, a fordító úgy alakítja át az értékeket, hogy ne veszít- 
sünk információt. Sajnos az információvesztéssel járó átalakítások is automatikusan végre- 
hajtásra kerülnek. Ebben a részben az átalakítási szabályokról, az átalakítások problémáiról 
és ezek következményeiről lesz szó. 


C.6.1. Kiterjesztések 


Azokat az automatikus átalakításokat, melyek megőrzik az értékeket, közösen kiterjeszté- 
seknek (promotion) nevezzük. Mielőtt egy aritmetikai műveletet végrehajtunk, egy egész tí- 
busú kiterjesztés az int típusnál kisebb értékeket int értékre alakítja. Figyeljünk rá, hogy 
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ezek a kiterjesztések nem long típusra alakítanak (hacsak valamelyik operandus nem 
wchar. t vagy olyan felsoroló érték, amely már eleve nagyobb, mint egy inD. Ez a kiterjesz- 
tés eredeti célját tükrözi a C nyelvben: az operandusokat , természetes" méretűre akarjuk 
alakítani az aritmetikai műveletek elvégzése előtt. 


Az egész típusú kiterjesztések a következők: 


6 A cchar, signed char, unsigned char, short int és unsigned short int értékeket 
int típusúra alakítja a rendszer, ha az int az adott típus összes értékét képes áb- 
rázolni; ellenkező esetben a céltípus unsigned int lesz. 

6 A wchar. ttípust (§4.3) és a felsoroló típusokat (44.8) a rendszer a következő lis- 
ta első olyan típusára alakítja, amely ábrázolni tudja a megfelelő típus összes ér- 
tékét: int, unsigned int, long, unsigned long. 

6 Apbitmezők (4C.8.1) int típusúak lesznek, ha az képes a bitmező összes értékét 
ábrázolni. Ha az int nem, de az unsigned int képes erre, akkor az utóbbi lesz 
a céltípus. Ha ez sem valósítható meg, akkor nem következik be egész típusú 
kiterjesztés. 

6 Logikai értékek int típusra alakítása: a false értékből O, a true értékből 7 lesz. 


A kiterjesztések a szokásos aritmetikai átalakítások részét képezik. (4C.6.3) 


C.6.2. Átalakítások 


Az alaptípusok számos módon alakíthatók át: véleményem szerint túl sok is az engedélye- 
Zett átalakítás: 


void (double d) 
( 


char c — d; // vigyázat: kétszeres pontosságú lebegőpontos érték átalakítása 


karakterre 


J 


Amikor programot írunk, mindig figyelnünk kell arra, hogy elkerüljük a nem meghatározott 
szolgáltatásokat és azokat az átalakításokat, melyek , szó nélkül" tüntetnek el információkat. 
A fordítók a legtöbb veszélyes átalakításra figyelmeztethetnek és szerencsére általában meg 
is teszik. 
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C.6.2.1. Egész átalakítások 


Egy egész érték bármely más egész típusra átalakítható, de a felsoroló értékeket is egész tí- 
pusokra alakíthatjuk. 


Ha a céltípus előjel nélküli, az eredmény egyszerűen annyi bit lesz a forrásból, amennyi 
a céltípusban elfér. (Ha kell, a magas helyiértékékű biteket a rendszer eldobja.) Pontosab- 
ban fogalmazva, az eredmény a legkisebb olyan egész, amelynek osztása a 2 n-edik hatvá- 
nyával azonos értéket ad, mint a forrásérték hasonló osztása, ahol n az előjel nélküli típus 
ábrázolásához használt bitek száma. Például: 


unsigned char uc - 1023;  / bináris 1111111111: uc bináris 11111111 lesz; ami 255 


Ha a céltípus előjeles és az átalakítandó érték ábrázolható vele, az érték nem változik meg. 
Ha a céltípus nem tudja ábrázolni az értéket, az eredmény az adott nyelvi változattól függő 
lesz: 


signed char sc - 1023; // megvalósítás-függő 
A lehetséges eredmények: 7127 és -1 (4C.3.4). 
A logikai és felsoroló értékek automatikusan a megfelelő egész típusra alakíthatók (§4.2, 
44.89. 
C.6.2.2. Lebegőpontos átalakítások 
Lebegőpontos értékeket más lebegőpontos típusokra alakíthatunk át. Ha a forrásérték pon- 
tosan ábrázolható a céltípusban, az eredmény az eredeti számérték lesz. Ha a forrásérték 


a céltípus két egymást követő ábrázolható értéke között áll, eredményként ezen két érték 
valamelyikét kapjuk. A többi esetben az eredmény nem meghatározható: 


float f - FIT MAX; // a legnagyobb lebegőpontos érték 
double d — f; // rendben: d -——- f 

float f2 — d; // rendben: f2 -——- f 

double d3 - DBL MAX; // a legnagyobb double érték 


float f3 - d3; // nem meghatározott, ha FLI. MAXZDBL MAX 
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C.6.2.3. Mutató- és hivatkozás-átalakítások 


Az objektumtípusra hivatkozó mutatók mind void" (§5.6) típusúra alakíthatók; a leszárma- 
zott osztályra hivatkozó mutatók és hivatkozások bármelyike átalakítható egy elérhető és 
egyértelmű alaposztályra hivatkozó mutató, illetve hivatkozás típusára (412.2). Fontos vi- 
szont, hogy egy függvényre vagy egy tagra hivatkozó mutató automatikusan nem alakítha- 
tó void"típusra. 


A O értékű konstans kifejezések (4C.5) bármilyen mutató és tagra hivatkozó mutató (§5.1.1) 
típusra automatikusan átalakíthatók: 


int p — 


Egy T"érték automatikusan const T"típusra alakítható (§5.4.1) és ugyanígy egy 76 érték is 
átalakítható const 716 típusra. 


C.6.2.4. Tagra hivatkozó mutatók átalakítása 


A tagokra hivatkozó mutatók és hivatkozások úgy alakíthatók át automatikusan, ahogy 
a §15.5.1 pontban leírtuk. 


C.6.2.5. Logikai értékek átalakítása 


A mutatók, egészek és lebegőpontos értékek automatikusan bool típusúvá alakíthatók 
(44.29. A nem nulla értékek eredménye true, a nulla eredménye false lesz: 


void fint" p, int i) 
t 
boolis not zero — p; // igaz, ha p/-O 
bool b2 - í; // igaz, ha i!-O 
4 
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C.6.2.6. Lebegőpontos-egész átalakítások 


Amikor egy lebegőpontos értéket egésszé alakítunk, a törtrész elveszik, vagyis a lebegő- 
pontosról egészre való átalakítás csonkolást eredményez. Az int(1.6) értéke például 7 lesz. 
Ha a csonkolással keletkező érték sem ábrázolható a céltípusban, az eredmény nem meg- 
határozhatónak minősül: 


int i — 2.7; // i értéke 2 lesz 
char b - 2000.7; . // nem meghatározott 8 bites char típusra: a 2000 nem ábrázolható 
// 8 bites karakterben 


Az egészről lebegőpontosra való átalakítás matematikailag annyira pontos, amennyire 
a hardver megengedi. Ha egy egész érték egy lebegőpontos típus értékeként nem ábrázol- 
ható, az eredmény nem lesz egészen pontos: 


int i - float(1234567890); 


Itt az i értéke 123456 7936 lesz az olyan gépeken, amely az intés a float ábrázolására is 32 
bitet használnak. 


Természetesen célszerű elkerülni az olyan automatikus átalakításokat, ahol információt ve- 
szíthetünk. A fordítók képesek észlelni néhány veszélyes átalakítást, például a lebegőpon- 
tosról egészre vagy a long int típusról char típusra valót, ennek ellenére az általános, fordí- 
tási időben történő ellenőrzés nem mindig kellően megbízható, ezért a programozónak elő- 
vigyázatosnak kell lennie. Amennyiben az elővigyázatosság nem elegendő, a programozó- 
nak ellenőrzéseket kell beiktatnia a hibák elkerülésére: 


class check failed ( J; 


char checked(int i) 

t 
char c — í; // figyelem: nem hordozható ($C.6.2.1 
if G !- c) throw check failedO; 
return c; 

) 

void my code(Cint i) 

t 
char c — checked; 
sző 

) 


Ha úgy szeretnénk csonkolást végezni, hogy a program más rendszerre is változtatás nél- 
kül átvihető legyen, vegyük figyelembe a numeric limits-ben (§22.2) megadottakat. 
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C.6.3. Szokásos aritmetikai átalakítások 


Ezek az átalakítások akkor következnek be, ha egy kétoperandusú (bináris) művelet két 
operandusát közös típusúra kell alakítani. Ez a közös típus határozza meg az eredmény tí- 


pusát is. 


1. Ha az egyik operandus long double típusú, a rendszer a másikat is long double 


típusúvá alakítja. 


Ha egyik sem long double, de valamelyik double, a másik is double típusúvá 
alakul. 

Ha egyik sem double, de valamelyik float, a másik is float értékre lesz átala- 
kítva. 

Ha a fentiek egyike sem teljesül, a rendszer mindkét operandusra egész ki- 
terjesztést (4C.6.1) alkalmaz. 


2. Ezután, ha valamelyik operandus unsigned long, akkor a másik is unsigned 


long lesz. 


Ha a fenti nem teljesül, de az egyik operandus long int, a másik pedig 
unsigned int, és a long int típus képes ábrázolni az összes unsigned int ér- 
téket, akkor az unsigned int értéket a fordító /ong int típusúra alakítja. Ha 

a long int nem elég nagy, mindkét értéket unsigned long int típusra kell ala- 
kítani. 

Ha a fenti nem teljesül, de valamelyik operandus /ong, a másik is long típu- 
súra alakul. 

Ha valamelyik operandus unsigned, a másik is unsigned értékre alakul. 

Ha a fentiek egyike sem teljesül, mindkét érték int lesz. 


C.7. Többdimenziós tömbök 


Nem ritka, hogy vektorok vektorára van szükségünk, sőt vektorok vektorainak vektorára. 
A kérdés az, hogy a Ct4-ban hogyan ábrázolhatjuk ezeket a többdimenziós tömböket. Eb- 
ben a pontban először megmutatjuk, hogyan használjuk a standard könyvtár vector osztá- 


lyát erre a célra, majd megvizsgáljuk, hogyan kezelhetők a többdimenziós tömbök a C-ben 
és a C44-ban akkor, ha csak a beépített lehetőségek állnak rendelkezésünkre. 
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C.7.1. Vektorok 
A szabványos vector (§16.3) egy nagyon általános megoldást kínál: 


vectorg vectorcint: 5 m(3, vectorsint:(599; 


Ezzel az utasítással egy 3 olyan vektort tartalmazó vektort hozunk létre, melyek mindegyi- 
ke 5 darab egész érték tárolására képes. Mind a 15 egész elem a 0 alapértelmezett értéket 
kapja, melyet a következő módon módosíthatunk: 


void init mO 
( 
for Gnt i — O; izm.sizeO; it) ( 
for (int j — O, jemlij.sizeO; jx1) mlillj] - 10"7i-j; 
) 
) 


Grafikusan ezt így ábrázolhatjuk: 
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A vector objektumot egy, az elemekre hivatkozó mutatóval és az elemek számával ábrázol- 
tuk. Az elemeket általában egy szokásos tömbben tároljuk. Szemléltetésképpen mindegyik 
egész elembe a koordinátáinak megfelelő értéket írtuk. 


Az egyes elemeket kétszeres indexeléssel érhetjük el. Az m/ij/[j/ kifejezés például az i-edik 
vektor 7-edik elemét választja ki. Az m elemeit a következőképpen írathatjuk ki: 
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void print mO 
A 
for Gnt i - O; izm.sizeO); ií33) ( 
for Gnt j — O; jeml[íj.sizeO; jt4) cout cz mliijlj] Sz M; 
cout cz Mt 


Ennek eredménye a következő lesz: 


01 2 3 4 
10 11 12 13 14 
20 21 22 23 24 


Figyeljük meg, hogy az m vektorok vektora, nem egyszerű többdimenziós tömb, ezért a gya- 
korlatban lehetőségünk van arra, hogy egyesével módosítsuk a belső vektorok méretét: 


void reshape m(int ns) 
Ű 
for Gnt i - O; izm.sizeO; it) mlil.resize(ms); 


J 


A vectork vectorsint: 5 szerkezetben szereplő vectorcint: vektorok méretének nem feltét- 
lenül kell azonosnak lennie. 


C.7.2. Tömbök 


A beépített tömbök jelentik a Ct--ban a legfőbb hibaforrást, különösen ha többdimenziós 
tömbök készítésére használjuk fel azokat. Kezdők számára ezek okozzák a legtöbb kevere- 
dést is, ezért amikor lehet, használjuk helyettük a vector, list, valarray, string stb. osztályokat. 


A többdimenziós tömböket tömbök tömbjeként ábrázolhatjuk. Egy 3x5-ös méretű tömböt 
az alábbi módon vezethetünk be: 


int ma(3] 5]; // 3 tömb, mindegyikben 5 int elem 
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Az ma adatszetkezetet a következőképpen tölthetjük fel: 


void init maO 
t 
for (int i - O; i£3; it) ( 
for Gnt j — O; já5S; jr1) madlij[[j] - 1077; 
) 
Ji 


Ábrával: 

















ma: 100 01102 103 0410 11 121314 20121 22 [23]24 


Az ma tömb egyszerűen 15 egész értéket tárol, melyeket úgy érünk el, mintha 3 darab 5 ele- 
mű tömbről lenne szó. Tehát a memóriában nincs olyan objektum, amely magát az ma mát- 
rixot jelenti, csak az önálló elemeket tároljuk. A 3 és 5 dimenzióértékek csak a forrásban je- 
lennek meg. Amikor ilyen programot írunk, nekünk kell valahogy emlékeznünk az értékek- 
re. Az ma tömböt például a következő kódrészlet segítségével írathatjuk ki: 





void print maO 
t 
for (int i - O; i£3; it) ( 
for (int j — O; já5; jt4) cout cz madlijlj] Sz M; 
cout cz Mt 


Az a vesszős jelölés, amit néhány nyelv a többdimenziós tömbök kezeléséhez biztosít, 
a Ct4-ban nem használható, mert a vessző ( ) a műveletsorozat-operátor (46.2.29. Szeren- 
csére a fordító a legtöbb hibára figyelmeztethet: 


int bad[3,5]; // hiba: a vessző nem megengedett konstans kifejezésben 
int good[3/]/5]; // 3 tömb, mindegyikben 5 int elem 
int ouch - good[1,4]; // hiba: int kezdőértéke nem lehet int" típusú (good[1,4/ 


// jelentése good[4l, ami int" típus) 
int nice - good[1[[ál; // helyes 
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C.7.3. Többdimenziós tömbök átadása 


Képzeljünk el egy függvényt, mellyel egy többdimenziós tömböt akarunk feldolgozni. Ha 
a dimenziókat fordításkor ismerjük, nincs probléma: 


void print m35(int m(3/5D 
( 
for Gnt i — O; i£3; it5) ( 
for (int j — O; já5; jt4) cout cz mliijlj] Sz M; 
cout cz Mt 


A többdimenziós tömbként megjelenő mátrixokat egyszerűen mutatóként adjuk át (nem 
készül róla másolat, §5.3). Az első dimenzió érdektelen az egyes elemek helyének megha- 
tározásakor, csak azt rögzíti, hogy az adott típusból (esetünkben az int/5/bőb hány darab 
áll egymás után (esetünkben 59. Például, nézzük meg az ma előbbi ábrázolását. Megfigyel- 
hetjük, hogy ha csak annyit tudunk, hogy a második dimenzió 5, akkor is bármely malij[5/ 
elem helyét meg tudjuk állapítani. Ezért az első dimenziót átadhatjuk külön paraméterként: 


void print. miS(int m(J[57], int dim1) 
( 
for Gnt i - O; izdimTI; it) ( 
for (int j - O; já5; jt1) cout cz miijlj] Sz M; 
cout cz Mn 


A problémás eset az, ha mindkét dimenziót paraméterként akarjuk átadni. A , nyilvánvaló 
megoldás" nem működik: 


void print mij(int m(J/], int dim1, int dim2) // nem úgy viselkedik, 
// ahogy legtöbben gondolnánk 


E 
for (int í - O; izdim1T; it1) ( 
for (int j - O; jádim2; jt1) cout ca mliijlj] Sz Mt; // meglepetés! 
cout 2 Mi; 
) 
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Először is, az m(/// deklaráció hibás, mert egy többdimenziós tömb esetében a második di- 
menziót ismernünk kell ahhoz, hogy az elemek helyét meg tudjuk határozni. Másrészt, az 
mlij[j/ kifejezést (teljesen szabályosan) ((m-iJ--j)-ként értelmezi a fordító, ami általában 
nem azt jelenti, amit a programozó ki akart vele fejezni. A helyes megoldás a következő: 


void print mij(int" m, int dim1], int dim2) 
( 
for (int i - O; izdimI; í33) ( 
for (int j - O; jcdim2; jt1) cout cz mli"dim2--j] cz M; // zavaros 
cout cz Mt 


A print mijO függvényben az elemek eléréséhez használt kifejezés egyenértékű azzal, amit 
a fordító állít elő, amikor ismeri az utolsó dimenziót. 


Ennek a függvénynek a meghívásához a mátrixot egyszerű mutatóként adjuk át: 


int mainŐ 
t 
int ul31/5] - ( (0,1,2,3,4), (10,11,12,13, 14), (20, 21, 22, 23, 24) ); 


brint m35(09; 

brint mi5(v,3); 

print mij(GulOJ[OJ,3,59; 
] 


Figyeljük meg az utolsó sorban a 64/0//0/ kifejezés használatát. A 1/0/ szintén megfelelne, 
mert az előbbivel teljesen egyenértékű, a v viszont típushibát okozna. Az ilyen , csúnya" és 
körülményes programrészleteket jobb elrejteni. Ha közvetlenül többdimenziós tömbökkel 
kell foglalkoznunk, próbáljuk különválasztani a vele foglalkozó programrészleteket. Ezzel 
leegyszerűsíthetjük a következő programozó dolgát, akinek majd a programhoz hozzá kell 
nyúlnia. Ha külön megadunk egy többdimenziós tömb típust és benne egy megfelelő inde- 
xelő operátort, a legtöbb felhasználót megkímélhetjük attól, hogy az adatok fizikai elrende- 
zésével kelljen foglalkoznia (422.4.09. 


A szabványos vector (§16.3) osztályban ezek a problémák már nem jelentkeznek. 
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C.8. Ha kevés a memória... 


Ha komolyabb alkalmazást készítünk, gyakran több memóriára lenne szükségünk, mint 
amennyi rendelkezésünkre áll. Két módszer van arra, hogy több helyet préseljünk ki: 


1. Egyetlen bájtban több kisebb objektumot tárolhatunk. 
2. Ugyanazt a területet különböző időpontokban különböző objektumok tárolásá- 
ra használhatjuk. 


Az előbbit a mezők, az utóbbit az uniók segítségével valósíthatjuk meg. Ezekről az eszkö- 
zökről a korábbiakban már volt szó. A mezőket és az uniókat szinte csak optimalizáláshoz 
használjuk, ami gyakran a memória adott rendszerbeli felépítésén alapul, így a program 
nem lesz más rendszerre átvihető. Tehát érdemes kétszer is meggondolnunk, mielőtt eze- 
ket a szerkezeteket használjuk. Gyakran jobb megoldást jelent, ha az adatokat , másképp" 
kezeljük, például több dinamikusan lefoglalt területet (46.2.60) és kevesebb előre lefoglalt 
Cstatikus) memóriát használunk. 


C.8.1. Mezők 


Gyakran rettentő pazarlásnak tűnik, hogy egy bináris változót — például egy ki/be kapcso- 
lót — egy teljes bájt (char vagy booD felhasználásával ábrázolunk, de ez a legkisebb egység, 
amelyet a memóriában közvetlenül megcímezhetünk a C--- segítségével (45.19. Viszont, ha 
a struct típusban mezőket használunk, lehetőség van arra, hogy több ilyen kis változót 
egyetlen csomagba fogjunk össze. Egy tag akkor válik mezővé, ha utána megadjuk az álta- 
la elfoglalt bitek számát. Névtelen mezők is megengedettek. Ezek a C4- szempontjából nin- 
csenek hatással az elnevezett mezők jelentésére, segítségükkel azonban pontosan leírha- 
tunk bizonyos gépfüggő adatokat: 


struct PPN ( // R6G000 fizikai lapszám 
unsigned int PEN : 22; // lapkeret-szám 
int : 3; // nem használt 
unsigned int CCA : 3; // Cache Coherency Algorithm 


bool nonreachable : 1; 
bool dirty : 1; 
bool valid : 1; 
bool global : 1; 
]: 


Ezzel a példával a mezők másik legfontosabb felhasználási területét is bemutattuk: valami- 
lyen külső (nem C-t) szerkezet részeit is pontosan elnevezhetjük velük. A mezők egész 
vagy felsoroló típusúak (44.1.1). Egy mezőnek nem lehet lekérdezni a címét, viszont ettől 
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eltekintve teljesen átlagos változóként kezelhetjük. Figyeljük meg, hogy egy bool típusú ér- 
téket itt tényleg egy bittel ábrázolhatunk. Egy operációs rendszer magjában vagy egy hiba- 
keresőben a PPNtípus a következőképpen használható: 


void part of VM system(PPN" p) 
( 
Mesa 


if (p-2dirty) ( // a tartalom megváltozott 
// lemezre másolás 
b-2dirty - 0; 
) 


MZEE 
J 


Meglepő módon, ha több változót mezők segítségével egyetlen bájtba sűrítünk össze, akkor 
sem feltétlenül takarítunk meg memóriát. Az adatterület csökken, de az ilyen adatok kezelésé- 
hez szükséges kód a legtöbb számítógépen jelentősen nagyobb. A programok mérete jelentő- 
sen csökkenthető azzal, hogy a bitmezőkként ábrázolt bináris adatokat char típusra alakítjuk, 
ráadásul egy char vagy int elérése általában sokkal gyorsabb, mint a bitmezők elérése. A me- 
zők csak egy kényelmes rövidítést adnak a bitenkénti logikai műveletekhez (46.2.4), hogy egy 
gépi szó részeibe egymástól függetlenül tudjunk adatokat írni, illetve onnan kiolvasni. 


C.8.2. Uniók 


Az unió olyan struct, melyben minden tag ugyanarra a címre kerül a memóriában, így az 
unió csak annyi területet foglal, mint a legnagyobb tagja. Természetesen az unió egyszerre 
csak egy tagjának értékét tudja tárolni. Képzeljünk el például egy szimbólumtábla-bejegy- 
zést, amely egy nevet és egy értéket tárol: 


enum Type (5, I ]; 


struct Entry (í 
char?" name; 


Type I; 
char" s; // s használata, ha t--S 
int í; // i használata, ha t—— 
J; 
void Entry" p) 
t 


if (b-t —— 5) cout c£ p-os; 
ÉN 
V 
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Az s és az itagot sohasem fogjuk egyszerre használni, így feleslegesen pazaroltuk a memó- 
riát. Ezen a problémán könnyen segíthetünk a union adatszerkezet segítségével: 


union Value ( 
char" s; 
int í; 


J 


A rendszer nem tartja nyilván, hogy a union éppen melyik értéket tárolja, tehát ezt tovább- 
ra is a programozónak kell megtennie: 


struct Entry ( 
char" name; 


Type t 
Value u; // v.s használata, ha t--S; v.i használata, ha t-- 
J; 
void Entry" p) 
( 
if (pet -- 5) cout c£ p-ou.s; 
I as 
] 


Sajnos a union bevezetése arra kényszerít minket, hogy az egyszerű s helyett a v.s kifeje- 
zést használjuk. Ezt a problémát a névtelen unió segítségével kerülhetjük el, amely egy 
olyan unió, amelynek nincs neve, így típust sem ad meg, csak azt biztosítja, hogy tagjai 
ugyanarra a memóriacímre kerüljenek: 


struct Entry ( 
char" name; 


Type t; 
union í 
char" s; // s használata, ha t—— 
int i; // i használata, ha t—- 
J; 
J; 
void Entry" p) 
( 


if (P-t —— 5) cout 22 p-os; 
MV sss 
) 


Így az Entry szerkezetet használó programrészleteken nem kell változtatnunk. A union tí- 
pus olyan felhasználásakor, amikor egy értéket mindig abból a tagból olvasunk vissza, ame- 
lyiken keresztül írtuk, csak optimalizálást hajtunk végre. Az unió ilyen jellegű felhasználá- 
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sát azonban nem mindig könnyű biztosítani és a helytelen használat nagyon kellemetlen hi- 
bákat okozhat. A hibák elkerülése érdekében az uniót befoglalhatjuk egy olyan egységbe, 
amely biztosítja, hogy az érték típusa és a hozzáférés módja egymásnak megfelelő lesz 
(410.6I20D. Az uniót néha szándékosan helytelenül használjuk, valamiféle , típusátalakítás" 
érdekében. Ezt a lehetőséget általában azok a programozók használják, akik az explicit 
típusátalakítást nem támogató nyelven is írnak programokat. Ott az ilyen , csalásra" tényleg 
szükség van. Az alábbi szerkezettel az int és az int"típus közötti átalakítást próbáljuk meg- 
valósítani, egyszerű bitenkénti egyenértékűség feltételezésével: 


union Fudge ( 
int í; 
int" p; 

fa 


int" cheat(int i) 
( 
Fudge a; 
ai — it; 
return a.p; // hibás használat 


] 


Ez valójában nem is igazi átalakítás. Bizonyos gépeken az intés az int"nem ugyanannyi he- 
lyet foglal, más gépeken az egész értékeknek nem lehet páratlan címe. Tehát az unió ilyen 
felhasználása nagyon veszélyes és nem is vihető át más rendszerre, ráadásul ugyanerre 
a feladatra van egy egyszerűbb, biztonságosabb és , hordozható" megoldás: a meghatáro- 
zott (explicit) típusátalakítás (46.2.7). 


Az uniót időnként szándékosan a típusátalakítás elkerülésére használják. Például szüksé- 
günk lehet arra, hogy a Fudge segítségével megállapítsuk, hogy a 0 mutatót hogyan ábrá- 
zolja a rendszer: 


int mainŐ 

( 
Fudge foo; 
Jfoo.p — 0; 


cout c£ "A 0 mutató egész értéke: " SZ foo.i cz MM; 


) 
C.8.3. Uniók és osztályok 


A bonyolultabb uniók esetében gyakran előfordul, hogy egyes tagok jóval nagyobbak, mint 
a rendszeresen használt tagok. Mivel a union mérete legalább akkora, mint a legnagyobb 
tagja, sok helyet elpazarolhatunk így. A pazarlást általában elkerülhetjük, ha unió helyett 
származtatott osztályokat használunk. 
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Egy konstruktorral, destruktorral és másoló művelettel rendelkező osztály nem tartozhat 
egy unió tag típusába (410.4.12), hiszen a fordító nem tudja, melyik tagot kell törölnie. 


C.9. Memóriakezelés 


A C44-ban a memória kezelésére három alapvető módszer áll rendelkezésünkre: 


Statikus memória: Ebben az esetben az objektum számára az összeszerkesztő 
Cdinker) foglal helyet a program teljes futási idejére. Statikus memóriában kap- 
nak helyet a globális és névtér-változók, a static adattagok (410.2.4) és a függvé- 
nyekben szereplő static változók (§47.1.29. Azok az objektumok, melyek a stati- 
kus memóriában kapnak helyet, egyszer jönnek létre és a program végéig létez- 
nek. Címük a program futása közben nem változik meg. A statikus objektumok 
a szálakat (osztott című memóriaterületeket párhuzamosan) használó progra- 
mokban problémát jelenthetnek, mert a megfelelő eléréshez zárolásokat kell al- 
kalmaznunk. 

Automatikus memória: Ezen a területen a függvényparaméterek és helyi változók 
jönnek létre. A függvény vagy blokk minden egyes lefutásakor saját példányok 
jönnek létre az ilyen változókból. Ezt a típusú memóriát automatikusan foglalja 
le és szabadítja fel a rendszer, ezért kapta az automatikus memória nevet. 

Az automatikus memóriára gyakran hivatkozunk úgy, hogy az elemek ,a verem- 
ben helyezkednek el". Ha feltétlenül hangsúlyozni akarjuk ezt a típusú helyfog- 
lalást, a Ct-4t-ban az auto kulcsszót használhatjuk. 

Szabad tár. Erről a területről a program bármikor közvetlenül igényelhet memóriát 
és bármikor felszabadíthatja az itt lefoglalt területeket (a new, illetve a delete 
operátor segítségével. Amikor a programnak újabb területekre van szüksége 
a szabad tárból, a new operátorral igényelhet az operációs rendszertől. A sza- 
bad tárra gyakran hivatkozunk dinamikus memória vagy kupac (heap) néven 
is. A szabad tár a program teljes élettartama alatt csak nőhet, mert az ilyen terü- 
leteket a program befejeződéséig nem adjuk vissza az operációs rendszernek, 
így más programok azokat nem használhatják. 


A programozó szemszögéből az automatikus és a statikus tár egyszerűen, biztonságosan és 
automatikusan kezelhető. Az érdekes kérdést a szabad tár kezelése jelenti. A new segítsé- 
gével könnyen foglalhatunk területeket, de ha nincs következetes stratégiánk a memória 


felszabadítására (a memória visszaadására a szabad tár kezelőjének), a memória előbb- 
utóbb elfogy, főleg ha programunk elég sokáig fut. 
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A legegyszerűbb módszer, ha automatikus objektumokat használunk a szabad tárban levő 
objektumok kezeléséhez. Ennek megfelelően a tárolókat sokszor úgy valósítják meg, hogy 
a szabad tárban levő elemekre mutatókat állítanak (425.79. Az automatikus Szring-ek 
(§11.12) például a szabad tárban levő karaktersorozatokat kezelik és automatikusan felsza- 
badítják a területet, amikor kikerülnek a hatókörből. Az összes szabványos tároló (416.3, 17. 
fejezet, 20. fejezet, §22.4) kényelmesen megvalósítható ilyen formában. 


C.9.1. Automatikus szemétgyűjtés 


Ha ez az egyszerű megoldás nem felel meg igényeinknek, akkor használhatunk valamilyen 
memóriakezelő rendszert, amely megkeresi az olyan objektumokat, melyekre már nincs hi- 
vatkozás, és az ezek által lefoglalt memóriaterületet elérhetővé teszi új objektumok számá- 
ra. Ezt a rendszert általában automatikus szemétgyűjtő algoritmusnak vagy egyszerűen sze- 
métgyűjtőnek (garbage collection) nevezzük. 


A szemétgyűjtés alapötlete az, hogy ha egy objektumra már sehonnan sem hivatkozunk 


a programból, arra a későbbiekben sem fogunk, tehát az általa lefoglalt memóriaterületet 
biztonságosan felszabadíthatjuk vagy odaadhatjuk más objektumoknak: 


void JO 
( 
inf" p —- new int; 
42 
char" g - new char; 
J 


Itt a b-0 értékadás törli az egyetlen hivatkozást, ami a p által eddig meghatározott int ob- 
jektumra mutatott, így ezen int érték területét odaadhatjuk egy új objektumnak. A char tí- 
pusú objektum tehát már szerepelhet ugyanezen a memóriaterületen, ami azt jelenti, hogy 
a g ugyanazt az értéket kapja, mint eredetileg a p. 


A szabvány nem követeli meg, hogy minden nyelvi változat tartalmazza a szemétgyűjtést, de 
egyre gyakrabban használják az olyan területeken, ahol a C-t4-ban a szabad tár egyéni keze- 
lése költségesebb, mint a szemétgyűjtés. Amikor a két módszer költségeit összehasonlítjuk, fi- 
gyelembe kell vennünk a futási időt, a memória-felhasználást, a megbízhatóságot, a hordoz- 
hatóságot, a programozás pénzbeli költségeit és a teljesítmény megjósolhatóságát is. 
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C.9.1.1. Rejtett mutatók 


Mikor nevezhetünk egy objektumot hivatkozás nélkülinek? Vizsgáljuk meg például az aláb- 
bi programrészletet: 


void JO 

t 
int" p - new int; 
long i1 - reinterpret castzlong2x(p)JGOxFFFFO000; 
long i2 - reinterpret castzlong2x(p)JG0x0000FFFE; 
b- 0; 


// 641 pont: nem létezik az int-re hivatkozó mutató 


b - reinterpret castzinto(i1 li2); 
// itt az int-re ismét létezik mutató 


J 


Ha egy programban bizonyos mutatókat időnként nem mutatóként tárolunk, akkor , rejtett 
mutatókról" beszélünk. Esetünkben azt a mutatót, amit eredetileg a p változó tárolt, elrejtet- 


tük az i1 és az i2 egészekben. A szemétgyűjtő rendszertől azonban nem várhatjuk el, hogy 


kezelni tudja a rejtett mutatókat, tehát amikor a program a £17 ponthoz ér, a szemétgyűjtő 
felszabadítja az int érték számára lefoglalt területet. Valójában az ilyen programok helyes 
működését még az olyan rendszerekben sem garantálhatjuk, ahol nem használunk szemét- 


gyűjtő algoritmust, mert a reinterpret cast használata egészek és mutatók közötti 
típusátalakításra még a legjobb esetben is megvalósítás-függő. 


Az olyan union objektumok, melyek lehetővé teszik mutatók és nem mutatók tárolását is, 


külön problémát jelentenek a szemétgyűjtők számára. Általában nincs mód annak megálla- 
pítására, hogy egy ilyen szerkezet éppen mutatót tárol-e: 


union U ( // unió mutató és nem mutató taggal 
int p; 
int í; 


J; 


void KU u, U u2Z, U u3) 
t 
u.b - new int; 
u2.i - 999999; 
ui7-8; 


HV sza 
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A biztonságos feltételezés az, hogy minden érték mutató, ami egy ilyen union objektum- 
ban megjelenik. Egy kellően okos szemétgyűjtő ennél kicsit jobb megoldást is adhat. Pél- 
dául észreveheti, hogy (az adott rendszerben) int értékek nem helyezhetők el páratlan me- 
móriacímen és semmilyen objektumot nem hozhatunk létre olyan kicsi memóriacímen, 


mint a §. Ezek figyelembevételével a szemétgyűjtő algoritmusnak nem kell feltételeznie, 
hogy a 999999 vagy a 8 címen értelmes objektum szerepel, amit az /0 esetleg felhasznál. 


C.9.1.2. A delete 


Ha rendszerünk automatikus szemétgyűjtést használ, a memória felszabadításához nincs 
szükség a delete és a delete[/] operátorokra, tehát a szemétgyűjtést használó programozók- 
nak nem kell ezeket használniuk. A memória felszabadításán kívül azonban a delete és 
a delete[] destruktorok meghívására is használatos. 


Ha szemétgyűjtő algoritmust használunk, a 


delete p; 


utasítás meghívja a b által mutatott objektum destruktorát (ha van ilyen), viszont a memó- 
ria újrafelhasználását elhalaszthatjuk addig, amíg a memóriaterületre szükség lesz. Ha sok 
objektumot egyszerre szabadítunk fel, csökkenthetjük a memória feltöredeződésének mér- 
tékét (4C.9.1.4) Ez a megoldás ártalmatlanná teszi azt az egyébként rendkívül veszélyes hi- 
bát is, hogy ugyanazt az objektumot kétszer semmisítjük meg, amikor a destruktor csak 
a memória törlését végzi. 


Az olyan objektumok elérése, melyeket már töröltünk, szokás szerint nem meghatározható 
eredménnyel jár. 


C.9.1.3. Destruktorok 


Amikor a szemétgyűjtő algoritmus egy objektumot meg akar semmisíteni, két lehetőség kö- 
zül választhat: 


1. Meghívja az adott objektum destruktorát (ha az létezik). 

2. Feltételezi, hogy nyers memóriaterületről van szó és nem hív meg destruktort. 
Alapértelmezés szerint a szemétgyűjtő algoritmus a második lehetőséget használja, mert 
a new segítségével létrehozott, de a delete operátorral nem törölt objektumokat nem kell 


megsemmisítenünk. Tehát a szemétgyűjtő algoritmust bizonyos szempontból végtelen mé- 
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retű memória utánzásának tekinthetjük. Lehetőség van arra is, hogy a szemétgyűjtő algorit- 
must úgy valósítsuk meg, hogy a destruktor az algoritmus által , bejegyzett" objektumokra 
fusson le. A , bejegyzésre" azonban nincs szabványos megoldás. Figyeljünk arra, hogy az 
objektumokat mindig olyan sorrendben kell megsemmisítenünk, hogy az egyik objektum 
destruktora soha ne hivatkozzon olyan objektumra, amelyet korábban már töröltünk. 
A programozó segítsége nélkül ilyen sorrendet a szemétgyűjtő algoritmusok nagyon ritkán 
képesek betartani. 


C.9.1.4. A memória feltöredeződése 


Ha sok különböző méretű objektumot hozunk létre, illetve semmisítünk meg, a memória 
, feltöredeződik". Ez azt jelenti, hogy a memóriát olyan kis darabokban használjuk, amelyek 
túl kicsik ahhoz, hogy hatékonyan kezelhetők legyenek. Ennek oka az, hogy a memóriake- 
zelő rendszerek nem mindig találnak pontosan olyan méretű memóriadarabot, amilyenre 
egy adott objektumnak éppen szüksége van. Ha a kelleténél nagyobb területet használunk, 
a megmaradó memóriatöredék még kisebb lesz. Ha egy ilyen egyszerű memóriakezelővel 
programunk elég sokáig fut, nem ritka, hogy akár a rendelkezésre álló memória felét olyan 
memóriatöredékek töltik ki, melyek túl kis méretűek ahhoz, hogy használhatók legyenek. 


A memória-feltöredeződés problémájának kezelésére számos módszert dolgoztak ki. A leg- 
egyszerűbb megoldás, hogy csak nagyobb memóriadarabok lefoglalását tesszük lehetővé 
és minden ilyen darabban azonos méretű objektumokat tárolunk (415.3, §19.4.2). Mivel 
a legtöbb helyfoglalást kis méretű objektumok igénylik (például a tárolók elemei), ez 
a módszer nagyon hatékony lehet. Az eljárást akár egy önálló memóriafoglaló is automati- 
kusan megvalósíthatja. A memóriatöredeződést mindkét esetben tovább csökkenthetjük, 
ha az összes nagyobb memóriadarabot azonos méretűre (például a lapméretre) állítjuk, így 
ezek lefoglalása sem okoz töredeződést. 


A szemétgyűjtő rendszerek két fő típusba tartoznak: 


1. A másoló szemétgyűjtők az objektumokat áthelyezik a memóriában, ezzel egye- 
sítik a feltöredezett memória darabjait. 

2. A konzervatív szemétgyűjtők úgy próbálnak helyet foglalni az objektumoknak, 
hogy a memóriatöredeződés a lehető legkisebb legyen. 


A C44 szemszögéből a konzervatív szemétgyűjtők a gyakoribbak, mert rendkívül nehéz 
(sőt a komoly programokban valószínűleg lehetetlen) az objektumokat úgy áthelyezni, 
hogy minden mutatót helyesen átállítsunk. A konzervatív szemétgyűjtők azt is lehetővé te- 
szik, hogy a C44 programrészletek együttműködjenek akár a C nyelven készült program- 
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részletekkel is. A másoló szemétgyűjtőket többnyire csak olyan nyelvekben valósítják meg, 
melyek az objektumokat mindig közvetve — mutatókon vagy hivatkozásokon keresz- 
tül — érik el. (Ilyen nyelv például a Lisp vagy a Smalltalk.) Az olyan nagyobb programok 
esetében, melyeknél a memóriafoglaló és a lapkezelő rendszer közötti kapcsolattartás, illet- 


ve a másolás mennyisége jelentős, az újabb konzervatív szemétgyűjtők legalább olyan ha- 


tékonynak tűnnek, mint a másoló szemétgyűjtők. Kisebb programok esetében gyakran az 


a legjobb megoldás, ha egyáltalán nem használunk szemétgyűjtőt — főleg a C4- esetében, 
ahol az objektumok többségét természetszerűleg automatikusan kezelhetjük. 


C.10. Névterek 


Ebben a pontban olyan apróságokat vizsgálunk meg a névterekkel kapcsolatban, melyek 
csupán technikai részleteknek tűnnek, de a viták során, illetve a komoly programokban 
gyakran felszínre kerülnek. 


C.10.1. Kényelem és biztonság 
A using deklarációk egy új nevet vezetnek be a helyi hatókörbe, a using utasítások (direk- 
tívák) azonban nem így működnek, csak elérhetővé teszik a megadott hatókörben szerep- 


lő neveket: 


namespace X ( 


inti, j, k; 
J 
int k; 
void f1O 
( 
inti — 0; 
using namespace X; // az X-beli nevek elérhetővé tétele 
itt; // helyi i 
jet; 72 
kt; // hiba: X::k vagy globális k ? 
:ktt; // a globális k 
X::k4t; // az X-beli k 
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void [20 
t 
inti — 0; 
using X::i; // hiba: i kétszer deklarált f20-ben 
using X::j; 
using X::k; // elfedi a globális k nevet 
itt; 
jet; 4 X..j 
kt; 7 X::k 
J 


A helyileg (önálló deklarációval vagy using deklarációvaD bevezetett nevek elrejtik az 
ugyanilyen néven szereplő nem helyi neveket; a fordító pedig minden hibás túlterhelést 
a deklaráció helyén jelez. 


Figyeljük meg az f10 függvényben a kt- utasítás kétértelműségét. A globális nevek nem 
élveznek elsőbbséget azokkal a nevekkel szemben, melyek globális hatókörben elérhető 
névterekből származnak. Ez jelentős mértékben csökkenti a véletlen névkeveredések lehe- 
tőségét és biztosítja, hogy ne a globális névtér ,beszennyezésével" jussunk előnyökhöz. 


Amikor using utasítások segítségével olyan könyvtárakat teszünk elérhetővé, melyek sok 
nevet vezetnek be, komoly könnyítést jelent, hogy a felhasználatlan nevek ütközése nem 
okoz hibát. 


A globális névtér ugyanolyan, mint bármelyik másik, átlagos névtér. A globális névtér egyet- 
len különlegessége, hogy egy rá vonatkozó explicit minősítés esetében nem kell kiírnunk 
a nevét. Tehát a ::k jelölés azt jelenti, hogy ,keresd meg a k nevet a globális névtérben vagy 
a globális névtérhez using utasítással csatolt névterekben", míg az X::k jelentése: , keresd 
meg a k nevet az X névtérben, vagy a benne using utasítással megemlített névterekben" 


(48.2.3). 


Reméljük, hogy a névtereket használó új programokban radikálisan csökkenni fog a globá- 
lis nevek száma a hagyományos C és C--- programokhoz viszonyítva. A névterek szabálya- 
it kifejezetten úgy találták ki, hogy ne adjanak előnyöket a globális nevek , lusta" felhaszná- 
lóinak azokkal szemben, akik vigyáznak rá, hogy a globális hatókört ne ,szennyezzék 
össze". 
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C.10.2. Névterek egymásba ágyazása 


A névterek egyik nyilvánvaló felhasználási területe az, hogy deklarációk és definíciók vala- 
milyen értelemben zárt halmazát egyetlen egységbe fogjuk össze: 


namespace X ( 
// saját deklarációk 
J 


A deklarációk listája általában tartalmazni fog újabb névtereket is. Tehát gyakorlati okokból 
is szükség van a névterek egymásba ágyazására, azon egyszerű ok mellett, hogy ha valami- 
lyen rendszerben nem kifejezetten képtelenség az egymásba ágyazás megvalósítása, akkor 


illik azt lehetővé tennünk: 


void hO; 


namespace X ( 
void g0; 
Ms 
namespace Y ( 
void JO; 
void ffO; 
Ma 
j/ 
J 


Az alábbi jelölések a szokásos, hatókörökre vonatkozó, illetve minősítési szabályokból 
következnek: 


void X::Y::[JO 


t 
JO; gO; hO; 

v4 

void X::g0 

7 
JO; // hiba: nincs fO X-ben 
Y::fO; // rendben 

) 

void hO 

t 
Ja // hiba: nincs globális fO 
MEGÁ // hiba: nincs globális Y 
XfO; // hiba: nincs JO X-ben 
KXLY:.fO; // rendben 


/ 
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C.10.3. Névterek és osztályok 


A névterek elnevezett hatókörök, az osztályok pedig típusok, melyeket egy elnevezett ha- 
tókörrel határozunk meg, ami azt írja le, hogy a típus objektumait hogyan kell létrehozni és 
kezelni. Tehát a névtér egyszerűbb fogalom, mint az osztály, és ideális esetben az osztályo- 
kat úgy is meghatározhatjuk, mint további lehetőségeket biztosító névtereket. A meghatá- 
rozás azonban csak majdnem pontos, ugyanis a névtér nyitott szerkezet (48.2.9.3), míg az 
osztály teljesen zárt. A különbség abból adódik, hogy az osztályoknak objektumok szerke- 
zetét kell leírniuk, ez pedig nem engedi meg azt a szabadságot, amit a névterek nyújtanak. 
Ezenkívül a using deklarációk és using utasítások csak nagyon korlátozott esetekben hasz- 
nálhatók az osztályokra (415.2.29. 


Ha csak a nevek egységbe zárására van szükségünk, a névterek jobban használhatók, mint 
az osztályok, mert ekkor nincs szükségünk az osztályok komoly típusellenőrzési lehetősé- 
geire és az objektumkészítési módszerekre; az egyszerűbb névtér-kezelési elvek is elegen- 
dőek. 


C.11. Hozzáférés-szabályozás 


Ebben a pontban a hozzáférés-szabályozás olyan vonatkozásaira mutatunk példákat, me- 
lyekről a §15.3 pontban nem volt szó. 


C.11.1. Tagok elérése 
Vizsgáljuk meg az alábbi deklarációt: 


class X t 
// az alapértelmezés privát: 
int priv; 
brotected: 
int prot; 
bublic: 
int publ; 
void mO; 
]: 
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Az X::mO függvénynek korlátlan hozzáférése van a tagokhoz: 


void X::mO 

( 
priv — 1; // rendben 
prot — 2; // rendben 
publ — 3; // rendben 

J 


A származtatott osztályok tagjai a public és protected tagokat érhetik el (§15.239: 


class Y : public X ( 
void mderivedO; 
FA 


void Y::mderivedO 

( 
priv — 1; // hiba: priv privát 
brot - 2; // rendben: prot védett és mderivedOŐ az Y származtatott osztály tagja 
publ — 3; // rendben: publ nyilvános 

J 


A globális függvények csak a nyilvános tagokat látják: 


void fo" p) 

( 
Db-priv - I; // hiba: priv privát 
bp-prot — 2; // hiba: prot védett és fO se nem barát, se nem X vagy Y tagja 
p-publ - 3; // rendben: bubl nyilvános 

J 


C.11.2. Alaposztályok elérése 


A tagokhoz hasonlóan az alaposztályokat is bevezethetjük private, protected vagy public 
minősítéssel: 


class X( 

bublic: 
int a; 
Jaaa 

) 


class Y1 : public X ( ); 
class Y2 : protected X ( J; 
class Y3 : private X ( J; 
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Mivel az X nyilvános alaposztálya az Y17 osztálynak, bármely függvény szabadon (és auto- 
matikusan) átalakíthat egy Y7"értéket X"típusra és elérheti az X osztály nyilvános tagjait is: 


void (Y1" py1, Y2"py2, Y3" py3) 
t 


X" px - pyI; 
by1-2a — 7; 


bx -— pyz2; 
by2-a — [; 


bx - py3; 
by3--a — [; 


// rendben: X nyilvános alaposztálya Y1 osztálynak 
// rendben 


// hiba: X védett alaposztálya Y2 osztálynak 
// hiba 


// hiba: X privát alaposztálya Y3 osztálynak 
// hiba 


Vegyük az alábbi deklarációkat: 


class Y2 : protected X ( J; 
class 22 : public Y2 ( void (Y1", Y27, Y39; ); 


Mivel X védett alaposztálya Y2-nek, csak Y2 tagjai és barát (friend) osztályai, függvényei, il- 
letve Y2 leszármazottainak (például Z2-nek) tagjai és ezek barát elemei alakíthatják át (au- 
tomatikusan) az Y2"típusú értéket Xtra, és csak ezek férhetnek hozzá az X osztály public 


és protected tagjaihoz: 


void Z2-f(Y1"py1, Y2"py2, Y3" py3) 


( 
X" px - pyI; 
by1-a — 7; 
bx - py2; 
by2-a — 1 


bx -— py3; 
by3-a — 7; 


// rendben: X nyilvános alaposztálya Y1 osztálynak 
// rendben 


// rendben: X védett alaposztálya Y2-nek, 
// és 22 osztály Y2-ből származik 
// rendben 


// hiba: X privát alaposztálya Y3 osztálynak 
// hiba 


Végül vizsgáljuk meg az alábbit: 


class Y3 : private X ( void (17 Y27 Y37; J; 
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Az X az Y3-nak privát alaposztálya, így kizárólag Y3 tagjai és , barátai" alakíthatják át (auto- 
matikusan) az Y3"értékeket X-ra, és csak azok érhetik el az X nyilvános és védett tagjait: 


void Y3:((Y1"py1, Y2"py2, Y3"py3) 


( 
X"px - pyI; // rendben: X nyilvános alaposztálya Y1 osztálynak 
py1-ca - 7; // rendben 
bx - py2 // hiba: X védett alaposztálya Y2 osztálynak 
by2-a - 7; // hiba 
bx - py3; // rendben: X privát alaposztálya Y3-nak, és Y3::fO Y3 tagja 
bpy3-a - 7; // rendben 
J 


C.11.3. Tagosztályok elérése 


A tagosztályok tagjainak nincs különleges jogosultságuk a befoglaló osztály tagjainak eléré- 
sére és ugyanígy a befoglaló osztály tagjai sem rendelkeznek különleges hozzáféréssel a be- 
ágyazott osztály tagjaihoz. Minden a szokásos szabályok (§10.2.2) szerint működik: 


class Outer (í 
typedef int T; 
int í; 

bublic: 
int i2; 
static int s; 


class Inner (í 


int x; 
Ty; // hiba: Outer:: T privát 
public: 
void Outer" p, int v); 
7 
int gdnner" p); 
fa 
void Outer::IMner::fOuter" p, int v) 
( 
DP-Ci- u; // hiba: Outer::i privát 
D--i2 - u; // rendben: Outer::i2 nyilvános 


J 
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int Outer::g(Inner" p) 

t 
b-eofthis, 29; // rendben: Inner::fO nyilvános 
return p-2x; // hiba: Inner::x privát 


J 


Ennek ellenére gyakran hasznos, ha a beágyazott osztály elérheti a beágyazó osztály tagja- 
it. Ezt úgy érhetjük el, ha a tagosztályt friend minősítéssel vezetjük be: 


class Outer ( 
typedef int T; 


int í; 

bublic: 
class Inner; // a tagosztály előzetes bevezetése 
friend class Inner; // elérési jog Outer::Inner számára 


class Inner (í 
int Xx; 
Ty; // rendben: Inner egy "barát" 
bublic: 
void Outer" p, int v); 
]: 
]: 


void Outer::IMner::f Outer" p, int v) 
t 
D-i - u; // rendben: Inner egy "barát" 


J 


C.11.4. Barátok 
A friend minősítés hatása nem öröklődik és nem is tranzitív: 


class A ( 
friend class B; 
int a; 


J; 


class B ( 
friend class CG; 


J; 
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class C ( 
void CA" p) 
( 
b-2at4; — // hiba: C nem barátja A-nak, bár A barátjának barátja 
J 
J; 
class D : public B ( 
void A" p) 
( 
b-2at4; — // hiba: D nem barátja A-nak, bár A barátjából származik 
J 


J; 


C.12. Adattagokra hivatkozó mutatók 


Természetesen a tagokra hivatkozó mutatók (415.5) fogalma az adattagokra, valamint a rög- 
zített paraméterekkel és visszatérési értékkel rendelkező függvényekre vonatkozik: 


struct C ( 
const char" val; 
int í; 
void print(int x) ( cout c£ val cz x cz MM; ) 
int fIGnY); 
void f2O; 
C(const char" v) (f val — u; ) 


J; 


typedef void (C::"PMFDGnNV); // GC osztály egy int paraméterrel meghívható 
// tagfüggvényre hivatkozó mutató 

typedef const char? C::"PM; // GC osztály egy char" típusú adattagjára 
// hivatkozó mutató 


void (Cé z1, CS 22) 
t 
C"tp - 622: 
PMFI pf - 6C::print; 
PM pm - 6C-::val; 


Z1.print( 1; 
(21.ppO; 
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z1.pm — "nv1 "; 
b-2"pm — "nv2 "; 


Z2.print(3); 

(b-2 pp; 

pf7- ECf1; // hiba: nem megfelelő visszatérési típus 
pf7- GC.f2 // hiba: nem megfelelő paramétertípus 
bpm - ECi; // hiba: nem megfelelő típus 

bm - pf; // hiba: nem megfelelő típus 


A függvényekre hivatkozó mutatók típusát a rendszer ugyanúgy ellenőrzi, mint bármely 
más típusét. 


C.13. Sablonok 


A sablon osztályok azt határozzák meg, hogyan hozható létre egy osztály, ha a szükséges 
sablonparamétereket megadjuk. A sablon függvények ehhez hasonlóan azt rögzítik, ho- 
gyan készíthetünk el egy konkrét függvényt a megadott sablonparaméterekkel. Tehát a sab- 
lonok típusok és futtatható kódrészletek létrehozásához használhatók fel. Ez a nagy kifeje- 
zőerő azonban néhány bonyodalmat okoz. A legtöbb probléma abból adódik, hogy más 
környezet áll rendelkezésünkre a sablon meghatározásakor és felhasználásakor. 


C.13.1. Statikus tagok 


Az osztálysablonoknak is lehetnek szatic tagjaik. Ezekből a tagokból minden, a sablonból 
létrehozott osztály saját példánnyal rendelkezik. A statikus tagokat külön kell meghatároz- 
nunk, de egyedi célú változatokat is készíthetünk belőlük: 


templatexclass T- class X€ 

VÁNYA 

static T def val; 

static T" new X(T a - def vaD; 
]: 


templatexclass T- T X2ZT5::def val(0, 09; 
templatexclass T2 T" XST2::new X(Ta)t/57...71 
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templateS2 int Xzint:::def. valszint: - 0; 
templateS2 int" Xzint:::new Xzintx(int) (/5... 7] 


Ha egy objektumot vagy függvényt a sablonból létrehozott összes osztály összes példányá- 
ban közösen szeretnénk használni, bevezethetünk egy alaposztályt, amely nem sablon: 


struct B ( 
static B" nil; // közös nullpointer minden B-ből származtatott osztálynak 
FA 
templatexciass T: class X : public B ( 
Ms 
fa 
B" B:nil — 0; 


C.13.2. Barátok és sablonok 


Más osztályokhoz hasonlóan a sablon is tartalmazhat friend osztályokat és függvényeket. 
Vizsgáljuk meg például a §11.5 pontban szereplő Matrix és Vector osztályt. Általában mind- 
két osztályt sablonként valósítjuk meg: 


templatexclass T- class Matrix; 


templatexcilass T: class Vector ( 
T ulál; 

bublic: 
friend Vector operator? £5 (const MatrixZT:6, const Vector6); 
78 

fa 


templatexcilass T- class Matrix ( 
VectorsT: ulál; 
bublic: 
friend Vector£T: operator? £5 (const MatrixG, const VectorcT:6); 


Lt 
] 


A barát függvény neve után szereplő c: jel nem hagyható el, mert ez jelzi, hogy a barát egy 
sablon függvény. A c: jel nélkül a rendszer nem sablon függvényt feltételezne. A fenti be- 
vezetés után a szorzás operátort úgy határozhatjuk meg, hogy a Vector és a Matrix tagjaira 
közvetlenül hivatkozunk: 
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templatexclass T: VectorST: operator? £5 (const MatrixZT:G, const Vector£T:6) 
( 
[7 ... m.vilíj és v.ulil használata az elemek közvetlen eléréséhez 


4 


A barát nincs hatással arra a hatókörre, melyben a sablon osztályt meghatároztuk, sem ar- 
ra, melyben a sablon osztályt felhasználjuk. Ehelyett a barát függvényeket és operátorokat 
paramétertípusaik alapján találja meg a rendszer (411.2.4, §11.5.19. A tagfüggvényekhez ha- 
sonlóan a barát függvényekből is csak akkor készül példány, ha meghívjuk azokat. 


C.13.3. Sablonok, mint sablonparaméterek 


Gyakran hasznos, ha sablonparaméterként osztályok vagy objektumok helyett sablonokat 
adunk át: 


templatecciass T, templatezclassz class C2 class Xrejd ( 


CST- mems; 

CST refs; 

1 sss 
] 
XrefdSEntry, vector: x1; // az Entry kereszthivatkozásokat vektorban tároljuk 
XrefdSRecord,set2 x2; // a Record kereszthivatkozásokat halmazban tároljuk 


Ahhoz, hogy egy sablont sablonparaméterként használjunk, meg kell adnunk az általa várt 
paramétereket, a paraméterként használt sablon sablonparamétereit viszont nem kell is- 
mernünk. Sablonokat általában akkor használunk sablonparaméterként, ha különböző pa- 
ramétertípusokkal akarjuk azokat példányosítani (fent például a Tés a 7T"típussaD. Tehát 
a sablon tagjainak deklarációit egy másik sablon fogalmaival fejezzük ki, de ez utóbbi sab- 
lont paraméterként szeretnénk megadni, hogy a felhasználó választhassa meg típusát. 


Ha a sablonnak egy tárolóra van szüksége azon elemek tárolásához, melyek típusát sablon- 
paraméterként kapja meg, gyakran egyszerűbb a tárolótípust átadni (413.6, §17.3.1. 


Sablonparaméterek csak sablon osztályok lehetnek. 
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C.13.4. Sablon függvények paramétereinek levezetése 


A fordító képes arra, hogy levezessen egy típus- (Tvagy TD vagy nem típus sablonparamé- 
tert (D egy olyan függvénysablon-paraméterből, melyet a következő szerkezetek valamelyi- 
kével állítottunk elő: 


T const T volatile T 

T" 16 Ikonstans kifejezés/ 
típus[1] osztálysablon néveT: osztálysablon névzI- 
TIST:- T2I- Tesz 

T típus::" Dés típus T::" 

T ( Xbaraméterek) típus (T::") (paraméterek)  T (típus:: (paraméterek) 


típus (típus::")(baraméterek TD TC(T::)(paraméterek TD típus (T::")(baraméterek TD 
T (típus:: )(baraméterek TD típus ( Xbaraméterek TD 


Ebben a gyűjteményben a param T1 egy olyan paraméterlista, melyből egy T vagy egy I 
meghatározható a fenti szabályok többszöri alkalmazásával, míg a param egy olyan para- 
méterlista, amely nem tesz lehetővé következtetést. Ha nem minden paraméter következ- 
tethető ki ezzel a megoldással, a hívás többértelműnek minősül: 


templatecxcilass T;, class U: void Kconst T" UC)y(U)); 
int 9g(GinV); 


void h(const char" p) 
( 

HD.8; // T char, U int 

HPEN; hiba: U nem vezethető le 
J 


Ha megnézzük az JÓ első hívásának paramétereit, könnyen kikövetkeztethetjük a sablon- 
paramétereket. Az /0 második meghívásában viszont láthatjuk, hogy a hO nem illeszthető 
az UC9(U) mintára, mert paramétere és visszatérési értéke különböző. 


Ha egy sablonparaméter egynél több függvényparaméterből is kikövetkeztethető, akkor 
mindegyiknek ugyanazt az eredményt kell adnia, ellenkező esetben hibaüzenetet kapunk: 


templatexclass T- void KT i, T" p); 


void g(int i) 
( 

Hi 61; // rendben 

JÍG, Vigyázat!); — // hiba, többértelmű: T int vagy T const char? 
J 
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C.13.5. A typename és a template 
Az általánosított (generikus) programozás további egyszerűsítése és még általánosabbá té- 
tele érdekében a standard könyvtár tárolói szabványos függvényeket és típusokat biztosíta- 


nak (§16.3. 1: 


templatexcilass T- class vector ( 
bublic: 

typedef T value type; 

typedef T" iterator; 


iterator begin; 
iterator endő; 


Ae 
]: 


templatexciass T- class list ( 
class link (/5... 7] 
bublic: 
typedef link" iterator; 


iterator begin; 
iterator endŐ; 


Ms 
]: 


Ez arra ösztönöz minket, hogy az alábbi formát használjuk: 


templatexclass C: void (CG v) 
t 

C:riterator i - v.beginO; // formai hiba 
J 


Sajnos a fordító nem gondolatolvasó, így nem tudja, hogy a C::iterator egy típus neve. Bi- 
zonyos esetekben egy okosabb fordító kitalálhatja, hogy egy nevet típusnévnek szántunk- 
e vagy valami egészen másnak (például függvény- vagy sablonnévnek), de ez általában 
nem lehetséges. Figyeljük meg például az alábbit: 


int y; 


templatecxcilass T- void g(IG v) 
t 

T::x(y;  / függvényhívás vagy változó-deklaráció? 
J 
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Feltétlenül igaz-e, hogy ez esetben a 7::x egy függvény, melyet az y paraméterrel hívtunk 
a zárójelek csak felesleges és természetellenes (de nem tiltotD) jelek. Tehát el tudunk kép- 
zelni olyan környezetet, melyben X::x(y) egy függvényhívás, míg az Y::x(y) egy deklaráció. 


A megoldás rendkívül egyszerű: ha mást nem mondunk, az azonosítókról a rendszer azt fel- 
tételezi, hogy olyasvalamire hivatkoznak, ami nem típus és nem sablon. Ha azt akarjuk kife- 
jezni, hogy egy azonosítót típusként kell értelmezni, a tybename kulcsszót kell használnunk: 


templatexclass C: void h(CG v) 

( 
typename C::iterator i — v.beginO; 
Ms 

J 


A typename kulcsszót a minősített név elé írva azt fejezhetjük ki, hogy a megadott elem egy 
típus. Ebből a szempontból szerepe hasonlít a struct és a class szerepére. 


A tybename kulcsszóra mindig szükség van, ha a típus neve egy sablonparamétertől függ: 


void k(vectorST:G6 v) 


( 
vectorST:::iterator i - v.beginO; // formai hiba: a "typename" hiányzik 
typename vectorST5::iterator i - v.beginO; — // rendben 
VES 

J 


Ebben az esetben a fordító esetleg képes lenne megállapítani, hogy az iterator a vector sab- 
lon minden példányosztályában egy típusnevet ad meg, de a szabvány ezt nem követeli 
meg. Tehát, ha egy fordító ilyesmire képes, akkor az nem szabványos szolgáltatás és nem 
tekinthető hordozható nyelvkiterjesztésnek. Az egyetlen környezet, ahol a fordítónak felté- 
teleznie kell, hogy egy sablon-paramétertől függő azonosító típusnév, az a néhány helyzet, 
amikor a nyelvtan csak típusneveket enged meg. Ilyenek például az alab-meghatározások 
(§A.8.1. 


A sablondeklarációkban a typename a class kulcsszó szinonimájaként is használható: 


templatestypename T: void f[(19; 


Mivel a két változat között nincs érdemi különbség, de a képernyő mindig kicsinek bizo- 
nyul, én a rövidebb változatot ajánlom: 


templatexclass T: void f(D; 
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C.13.6. Sablonok, mint minősítők 


A typename kulcsszó bevezetésére azért volt szükség, mert hivatkozhatunk olyan adatta- 
gokra is, melyek típusok, és olyanokra is, melyek nem azok. Ugyanilyen problémát jelent 
a sablontagok nevének megkülönböztetése más tagokétól. Vizsgáljuk meg például egy ál- 
talános memóriakezelő osztály egy lehetséges felületét: 


class Memory ( // valamilyen memóriafoglaló 
bublic: 

templatexclass T- T" get newO); 

templatecxciass T: void release( IE); 


I azis 

]: 

templatecxciass Allocator: void ((Allocators m) 

t 
inttp1 - m.get newcintxO; // formai hiba: int" a kisebb mint" operátor után 
int: p2 - m.template get newzint2O; // explicit minősítés 
Ve 
m.release(p1); // sablonparaméter levezetése: nem kell explicit minősítő 
m.release(p2; 

J 


A get newOfüggvény explicit minősítésére van szükség, mert a sablonparamétert nem le- 
het levezetni. Esetünkben a template előtagra van szükség ahhoz, hogy a fordítónak (és az 


emberi olvasónak) eláruljuk, hogy a get newO egy sablontag, tehát a minősítés lehetséges 
a megadott elemtípussal. A template minősítés nélkül formai hibát kapunk, mert a c jelet 
a fordító , kisebb, mint" operátorként próbálja meg értelmezni. A template kulcsszóval való 
minősítésre ritkán van szükség, mert a legtöbb esetben a sablonparamétereket a fordító ki 


tudja következtetni. 


C.13.7. Példányosítás 


Ha adott egy sablon-meghatározás és ezt a sablont használni szeretnénk, a fordító feladata, 
hogy a megfelelő programkódot előállítsa. Egy sablon osztályból és a megadott sablonpa- 
raméterekből a fordítónak elő kell állítania egy osztály meghatározását és összes olyan tag- 
függvényének definícióját, melyet programunkban felhasználtunk. Egy sablon függvény 


esetében a megfelelő függvényt kell előállítani. Ezt a folyamatot nevezzük a sablon példá- 
nyosításának. 
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A létrehozott osztályokat és függvényeket egyedi célú (,szakosított") változatoknak 
(specializációknak) nevezzük. Ha meg akarjuk különböztetni a fordító által automatikusan 
létrehozott változatokat a programozó által megadottaktól (413.5), akkor fordítói (generál) 
specializációkról, illetve explicit specializációkról beszélünk. Az explicit specializációkat 
néha felhasználói specializációknak nevezzük. 


Ahhoz, hogy a sablonokat bonyolultabb programokban is hatékonyan használhassuk, meg 
kell értenünk, hogy a sablon-meghatározásokban szereplő neveket hogyan köti a fordító 
konkrét deklarációkhoz és hogyan tudjuk forrásprogramunkat rendszerezni (413.79. 


Alapértelmezés szerint a fordító olyan sablonokból hoz létre osztályokat és függvényeket, 
melyeket a szokásos névkötési szabályok szerint használtunk (§C.13.8). Ez azt jelenti, hogy 
a programozónak nem kell megmondania, mely sablonok mely változatait kell elkészíteni. 
Ez azért fontos, mert a programozó általában nagyon nehezen tudja megmondani, hogy 
a sablonoknak pontosan mely változataira is van szüksége. A könyvtárak gyakran olyan 
sablonokat használnak, melyekről a programozó még nem is hallott, sőt az sem ritka, hogy 
egy, a programozó által egyáltalán nem ismert sablont annak számára szintén teljesen isme- 
retlen sablonparaméterekkel példányosítunk. Általában ahhoz, hogy megkeressük az 
összes olyan függvényt, melynek kódját a fordítónak elő kell állítania, az alkalmazásban és 
a könyvtárakban használt sablonok többszöri átvizsgálására van szükség. Az ilyen vizsgála- 
tok sokkal jobban illenek a számítógéphez, mint a programozóhoz. 


Ennek ellenére bizonyos helyzetekben fontos, hogy a programozó pontosan megmondhas- 
sa, a fordítónak hol kell elhelyeznie a sablonból létrehozott programrészleteket (4C.13.10). 
Ezzel a programozó pontosan szabályozhatja a példány környezetét. A legtöbb fordítási 
környezetben ez azt is jelenti, hogy pontosan rögzítjük, mikor jöjjön létre a példány. 
Az explicit példányosítás például jól használható arra, hogy a fordítási hibákat megjósolha- 
tó helyen és időben kapjuk, ne pedig ott és akkor, amikor az adott fordító úgy dönt, hogy 
létre kell hoznia egy példányt. Bizonyos körülmények között a tökéletesen megjósolható 
programkód-létrehozás elengedhetetlenül fontos lehet. 


C.13.8. Névkötés 


Nagyon fontos, hogy a sablon függvényeket úgy határozzuk meg, hogy a lehető legkisebb 
mértékben függjenek nem helyi adatoktól. Ennek oka az, hogy a sablonból ismeretlen típu- 
sok alapján, ismeretlen helyen fog a fordító függvényt vagy osztályt létrehozni. Minden ap- 
ró környezetfüggőség esélyes arra, hogy a programozó számára tesztelési problémaként je- 
lentkezzen, pedig a programozó valószínűleg egyáltalán nem is akar tudni a sablon megva- 
lósításának részleteiről. Az az általános szabály, miszerint amennyire csak lehet, el kell ke- 
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rülnünk a globális nevek használatát, a sablonok esetében még elengedhetetlenebb. Ezért 
a sablon-meghatározásokat próbáljuk annyira önállóvá tenni, amennyire csak lehet, és min- 
den olyan elemet, amelyet egyébként esetleg globális eszközökkel valósítanánk meg, sab- 
lonparaméterként adjunk át (pl. traits a §13.4 és a §20.2.1 pontban). 


Ennek ellenére kénytelenek vagyunk néhány nem helyi nevet is felhasználni. Sokkal gyak- 
rabban készítünk például egymással együttműködő sablon függvényeket, mint egyetlen 
nagy, önálló eljárást. Néha ezek a függvények jól összefoghatók egy osztályba, de nem min- 
dig. Időnként a nem helyi függvények használata mellett döntünk. Jellemző példa erre 
a sort függvényben szereplő swapO és lessŐ eljáráshívás (413.5.29. A standard könyvtár al- 
goritmusai nagyméretű példaként tekinthetők (§18. fejezet). 


A hagyományos névvel és szereppel megvalósított függvények (például a -, a "7 a //vagy 
a sortO) egy más jellegű forrást jelentenek a sablon-meghatározásokban levő nem helyi ne- 
vek használatára. Vizsgáljuk meg például az alábbi programrészletet: 


fincludeZvector: 


bool tracing; 


Mtss 
templatexclass T- T sum(std::vector£T:6 v) 
( 

Tt - 0; 


if (racing) cerr SZ "sum(" cz 6w cz "In; 
for (int í - O; izv.sizeO; 143) t-t 4 ulij; 
return t; 


4 

7288 

$includezguad.h: 

void f(std::vectorzOuad:G v) 
t 


Ouad c - sum(V); 
) 


Az ártatlan kinézetű sumO sablon függvény a 4 operátortól függ. Példánkban a - művele- 
tet a cguad.h: fejállomány határozza meg: 


Ouad operator (Ouad, Ouad); 
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Fontos, hogy a sum0O kifejtésekor semmilyen, a komplex számokhoz kapcsolódó elem nem 
elérhető és a sumO függvény megalkotója semmit sem feltételezhet a Ouad osztályról. Így 


könnyen előfordulhat például, hogy a 4 operátort jóval később határozzuk meg, mint 
a sumO eljárást, mind a program szövegében, mind időben. 


Azt a folyamatot, melynek során a fordító megkeresi a sablonban előforduló nevek dekla- 
rációját, névkötésnek (name binding) nevezzük. A sablonok névkötésénél a legnagyobb 
problémát az jelenti, hogy példányosításkor három különböző környezetet kell figyelembe 
venni és ezek nem választhatók el egymástól pontosan. A három környezet a következő: 


1. A sablon meghatározásának környezete 
2. A paramétertípus bevezetésének környezete 
3. A sablon felhasználási helyének környezete 


C.13.8.1. Függő nevek 


Amikor egy függvény sablont meghatározunk, biztosak szeretnénk lenni abban, hogy ren- 
delkezésünkre áll a megfelelő környezet, melyben az aktuális paraméterek fogalmaival el 
tudjuk végezni az adott feladatot, anélkül, hogy a felhasználási környezet elemeit , véletle- 
nül" beépítenénk az eljárásba. A nyelv ennek megvalósítását azzal segíti, hogy a sablon de- 
finíciójában felhasznált neveket két kategóriába osztja: 


1. A sablonparaméterektől függő nevek. Ezeket a neveket a példányosítás helyén 
köti le a fordító (4C.13.8.3). A sumO példafüggvényben a - operátor meghatáro- 
zása a példányosítási környezetben található, mert operandusaiban felhasználja 
a sablon típusparaméterét. 

2. A sablonparaméterektől független nevek. Ezeket a neveket a sablon meghatáro- 
zásánál köti le a fordító (§C.13.8.2). A sumO példafüggvényben a vector sablont 
a Cyector: szabványos fejállomány határozza meg, a logikai tracing változó pe- 
dig akkor is a hatókörben van, amikor a fordító találkozik a sumO függvény 
meghatározásával. 


Az ,N függ a T sablonparamétertől" kifejezés legegyszerűbb definíciója az lenne, hogy ,N 
tagja a Tosztálynak". Sajnos ez nem mindig elegendő: A Ouad elemek összeadása (4C.13.8) 
jó ellenpélda erre. Tehát egy függvényhívást egy sablonparamétertől függőnek akkor neve- 
zünk, ha az alábbi feltételek valamelyike teljesül: 


1. Az aktuális paraméter típusa függ egy Tsablonparamétertől a típuslevezetési 
szabályok szerint. Például f(IC109, RV, Hg(D) vagy KE1), ha feltételezzük, hogy 
ttípusa T: 
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2. A meghívott függvénynek van egy olyan formális paramétere, amely függ a Ttí- 
pustól, a típuslevezetési szabályok szerint (413.3.1). Például (DD, KdistcT:6) 
vagy fconst T". 


Alapjában véve azt mondhatjuk, hogy a meghívott függvény akkor függ egy sablonparamé- 
tertől, ha a konkrét és formális paramétereire nézve nyilvánvalóan függ tőle. 


Egy olyan hívás, melyben a függvény egyik paraméterének típusa véletlenül éppen megfe- 
lel az aktuális sablonparaméternek, nem jelent függőséget: 


templatexclass TET KT a) 
t 

return g(1; // hiba: nincs 90 a hatókörben és 2(1) nem függ T-től 
4 


void g(GinV); 


int z - f[D; 


Az nem számít, hogy az (2) hívásban a Téppen az int típust jelöli és a 90 paramétere is 
ilyen típusú. Ha a g(1) hívást függőnek tekintenénk, a sablon-meghatározás olvasójának 
a függvény jelentése teljesen érthetetlen lenne. Ha a programozó azt akarja, hogy a g(int) 
függvény fusson le, akkor a g(int-et be kell vezetnie az /0 kifejtése előtt, hogy a g(int) 
függvény elérhető legyen az /0 feldolgozásakor. Ez teljesen ugyanaz a szabály, mint a nem 
sablon függvények esetében. 


A függvényneveken kívül a változók, típusok, konstansok stb. neve is függő, ha típusuk 
függ a sablonparamétertől: 


templatecxciass T: void fci(const TE a) 

t 
typename T::Memtype p — a.p; // p és Memtype függ T-től 
cout ££ a.i cz! 2£ poj; // i és j függ T-től 

4 


C.13.8.2. Kötés meghatározáskor 


Amikor a fordító egy sablon meghatározásával találkozik, megállapítja, mely nevek függők 
(§C.13.8.19. Ha egy név függő, deklarációjának megkeresését el kell halasztanunk a példá- 
nyosításig (4C.13.8.3). 
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Azoknak a neveknek, melyek nem függnek sablonparaméterektől, a sablon meghatározá- 
sakor (definíciójánál) elérhetőnek kell lenniük (44.9.4): 


int X; 


templatexclass T: TK(T a) 


( 
Xtt; // rendben 
yt; // hiba: nincs y a hatókörben és y nem függ T-től 
return a; 

J 

int y; 

int z - 2; 


Ha a fordító talál megfelelő deklarációt, mindenképpen azt fogja használni, függetlenül at- 


tól, hogy később esetleg , jobb" deklarációt is találhatna hozzá: 
void g(double); 


templatexciass T- class X : public Tt 

bublic: 
void fOtg2; ) // g(double) meghívása 
Mag 

J; 


void g(inY); 
class Z ( J; 


void h(Xxsz: x) 
t 

x fO; 
) 


Amikor a fordító elkészíti az XSZ2::fŐO függvényt, nem a g(int) függvényt fogja használni, 
mert azt az X után vezettük be. Az nem számít, hogy az X sablont nem használjuk a g(int) 
bevezetése előtt. Ehhez hasonlóan egy független hívást sem téríthet el egy alaposztály: 


class Y ( public: void g(in0; J; 


void h(XxY5 x) 
t 

x JO; 
) 
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Az XZY2::fO most is a g(double) függvényt fogja meghívni. Ha a programozó az alaposz- 
tály g0 függvényét akarja használni, az /0 meghatározását a következőképpen kell megfo- 
galmaznia: 


templatexclass T- class XX : public T( 
void JO ( T::B(29; ) // T::gO meghívása 
ME 

J; 


Ez természetesen annak az alapszabálynak a megjelenése, hogy a sablon definíciójának 
a lehető legönállóbbnak kell lennie (§C.13.8). 


C.13.8.3. Kötés példányosításkor 


A sablon minden különböző sablonparaméter-halmazzal való felhasználásakor új 
példányosítási pontot határozunk meg. A példányosítási pont helye a legközelebbi globá- 
lis vagy névtér-hatókörben van, közvetlenül a felhasználást tartalmazó deklaráció előtt: 


templatecclass T: void (T a) ( g(a9; ) 
void g(in0); 


void hO 

t 
extern g(double); 
JD; 

4 


Esetünkben az f£int2O megfelelő példánya közvetlenül a AO előtt jön létre, tehát az 0 
függvényben meghívott g0 a globális g(in) lesz, nem pedig a helyi g(double). 
A ,példányosítási pont" meghatározásából következik, hogy a sablonparamétereket nem 
köthetjük helyi nevekhez vagy osztálytagokhoz: 


void JO 

t 
structX€£/5...7]1 // helyi szerkezet 
veclorSX2 u; // hiba: helyi szerkezet nem használható sablonparaméterként 
Méta 


J 
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Ugyanígy a sablonban használt minősítetlen neveket sem köthetjük helyi névhez. A minő- 
sítetlen nevek akkor sem fognak egy osztály tagjaihoz kötődni, ha a sablont először ebben 
az osztályban használjuk. A helyi nevek elkerülése nagyon fontos, ha nem akarunk szám- 
talan, ,makrószerű" problémával szembekerülni: 


templatexciass T: void sort(vectorZT:G v) 
t 
sort(v.beginŐ,v.endO); // standard könyvtárbeli sortO) használata 


class Container ( 
vectorcint: u; // elemek 
Messze 
bublic: 
void sortO // elemek rendezése 
( 
SOTH); // a sort(vectorsint26) meghívása a Container::sort() helyett 
7 
J/ ... 
FA 


Ha a sort(vectorSI:6) a sortO függvényt az std::sortO jelöléssel hívta volna meg, az ered- 
mény ugyanez lett volna, de program sokkal olvashatóbb lenne. 


Ha egy névtérben meghatározott sablon példányosítási pontja egy másik névtérben találha- 
tó, a névkötésnél mindkét névtér nevei rendelkezésre állnak. A fordító szokás szerint a túl- 
terhelési szabályokat használja arra, hogy megállapítsa, melyik névtér nevét kell használnia 


(48.2.9.2. 


Figyeljünk rá, hogy ha egy sablont többször használunk ugyanazokkal a sablonparaméterek- 
kel, mindig új példányosítási pontot határozunk meg. Ha a független neveket a különböző 
helyeken különböző nevekhez kötjük, programunk helytelen lesz. Az ilyen hibát nagyon ne- 
héz észrevenni egy alkalmazásban, főleg ha a példányosítási pontok különböző fordítási 
egységekben vannak. A legjobb, ha a névkötéssel járó problémákat kikerüljük azzal, hogy 
a lehető legkevesebb nem helyi nevet használjuk a sablonban és fejállományok segítségével 
biztosítjuk, hogy mindenhol a megfelelő környezet álljon a sablon rendelkezésére. 


C.13.8.4. Sablonok és névterek 


Amikor egy függvényt meghívunk, annak deklarációját a fordító akkor is megtalálhatja, ha 
az nincs is az aktuális hatókörben. Ehhez az kell, hogy a függvényt ugyanabban a névtér- 
ben vezessük be, mint valamelyik paraméterét (48.2.60). Ez nagyon fontos a sablon-megha- 
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tározásokban meghívott függvények szempontjából, mert ez a szolgáltatás teszi lehetővé, 
hogy a függő függvényeket a fordító a példányosítás közben megtalálja. 


A sablon egyedi célú változata a példányosítás tetszőleges pontján létrejöhet (4C.13.8.3), de 
a példányosítást követően az adott fordítási egységben, esetleg egy olyan fordítási egység- 
ben is, mely kifejezetten az egyedi célú változatok létrehozásához készült. Ebből három 
nyilvánvaló módszer alakítható ki az egyedi célú változatok elkészítéséhez: 


1. Akkor hozzuk létre azokat, amikor első meghívásukkal találkozunk. 

2. A fordítási egység végén létrehozzuk az összeset, amelyre az adott fordítási egy- 
ségben szükség van. 

3. Miután a program összes fordítási egységét megvizsgáltuk, a programban hasz- 
nált összes egyedi célú változatot egyszerre készítjük el. 


Mindhárom módszernek vannak előnyei és hátrányai, ezért gyakran ezen lehetőségek va- 
lamilyen párosítását használják. 


A független nevek kötését mindenképpen a sablon meghatározásakor végzi el a fordító. 


A függő nevek kötéséhez két dolgot kell megvizsgálni: 


1. A sablon meghatározásakor a hatókörben lévő neveket 
2. A függő hívások paramétereinek névterében szereplő neveket (a globális függ- 
vényeket úgy tekintjük, hogy a beépített típusok névterében szerepelnek) 


Például: 


namespace N ( 
class A(/5... 7]; 


char AJ; 
) 


char fini); 
templatexclass T- char g(T D ( return fOD; ) 


char c — 9(N::409; // N::f(N:: A) meghívását okozza 


Itt az (0) egyértelműen függő, így a definíció feldolgozásakor nem köthetjük sem az (int), 
sem az (/N::4) függvényhez. A gcN::A3(NV:: 4) , szakosításakor" a fordító az Nnévtérben ke- 
resi a meghívott /0 függvény meghatározását és ott az N::(IN:: 4) változatot találja meg. 
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A program hibás, ha különböző eredményeket kaphatunk azzal, hogy különböző példá- 
nyosítási pontokat választunk, vagy azzal, ha az egyedi célú változat létrehozásakor hasz- 
nált környezetekben a névterek tartalmát megváltoztatjuk: 


namespace N ( 
class At/7... 7; 


char (A in; 
) 


templatexciass T, class T22 char e(T t, T2 12) ( return Kt,t29; ) 


char c — g(N::AO, a); // hiba: ft) más feloldása is lehetséges 

namespace N ( // az N névtér kibővítése (§8.2.9.3) 
void fCA, char); 

) 


Ha a példányosítás pillanatában hozzuk létre a szakosított változatot, az ((N::A, int) függ- 
vény kerül meghívásra, viszont ha elkészítését a fordítási egység végére halasztjuk, a fordí- 
tó az ((N::A, char) függvényt találja meg előbb. Tehát a g(::4AO, a?) hívás helytelen. 


Nagyon rendetlen programozási stílust mutat, ha egy túlterhelt függvényt két deklarációja 
között hívunk meg. Egy nagyobb program esetében a programozó nem gyanakodna hibá- 
ra, ebben az esetben azonban a fordító képes észrevenni a többértelműséget. Hasonló 
problémák jelentkezhetnek különböző fordítási egységekben is, így a hibák észlelése már 
sokkal nehezebbé válik. Az egyes Ct-4-változatoknak nem kötelességük az ilyen típusú hi- 
bák figyelése. 


A függvényhívások többféle feloldási lehetőségének problémája leggyakrabban akkor je- 
lentkezik, amikor beépített típusokat használunk. Tehát a legtöbb hibát kiszűrhetjük azzal, 
hogy a beépített típusokat nagy körültekintéssel használjuk a paraméterekben. 


Szokás szerint a globális függvények csak még bonyolultabbá teszik a dolgokat. A globális 
névteret a beépített típusok szintjének tekinthetjük, így a globális függvények felhasználha- 
tók olyan függő függvények lekötésére is, melyeket beépített típusokkal hívtunk meg: 


int fin); 
templatexclass T- T g(T D ( return f09; ) 
char c - g(Ca)); // hiba: (1) más feloldása is lehetséges 


char (char); 
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A gccharr(char) függvény egyedi célú változatát elkészíthetjük a példányosítási ponton is; 
ekkor az (int) függvényt fogjuk használni. Ha a változatot a fordítási egység végén állítjuk 
elő, az (char) függvény fut majd le. Tehát a g(a ) hívás hibás. 


C.13.9. Mikor van szükség egyedi célú változatokra? 
Egy sablon osztály egyedi célú változatát csak akkor kell előállítani, ha az adott osztályra 


tényleg szükség van. Tehát amikor egy, az osztályra hivatkozó mutatót adunk meg, az osz- 
tály tényleges meghatározására még nincs szükségünk: 


class X; 
X"p; // rendben: X meghatározására nincs szükség 
X a; // hiba: X meghatározására szükség van 


A sablon osztályok meghatározásakor ez a különbség fontos lehet. A sablon osztályt mind- 
addig nem példányosítjuk, amíg arra nincs szükség: 


templatecxciass T- class Link (f 


Link" suc; // rendben: Link meghatározására (még) nincs szükség 
s 

]: 

Linkcint2" pl; // Tinkcint- béldányosítására nincs szükség 

Linkcint: Ink; // most van szükség Linksint- példányosítására 


A példányosítási pont az a hely, ahol a definícióra először szükség van. 


C.13.9.1. Sablon függvények példányosítása 


A fordító a sablon függvényeket csak akkor példányosítja, amikor a függvényt felhasznál- 
juk. Ennek megfelelően egy sablon osztály példányosítása nem vonja maga után sem összes 


tását. Ez nagy rugalmasságot biztosít a sablon osztályok meghatározásakor: 


templatexciass T- class List ( 
Hetes 
void sort; 

]: 
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class Glob ( /" nincs összehasonlító művelet "/ J; 


void f(tistzGlob:gG lb, Listsstring:€6 Is) 
T 
ls.sortO; 
// Ib műveleteinek használata, kivéve az Ib.sortO-ot 


/ 


Itt a ListSstring2::sortO függvényt a fordító példányosítja, de a List ZGlob:::sortO függvény- 
re nincs szükség. Ez egyrészt kevesebb kód létrehozását teszi lehetővé, másrészt megkímél 
minket attól, hogy az egész programot át kelljen szerveznünk. Ha a ListZGlob:::sortO függ- 
vényt is létrehozná a fordító, akkor a G/ob osztályban szerepelnie kellene az összes olyan 
műveletnek, melyet a Zist::sortO felhasznál, a sortO függvényt ki kellene vennünk a List sab- 
lonból, vagy a Gilob objektumokat kellene valamilyen más tárolóban tárolnunk. 


C.13.10. Explicit példányosítás 


A példányosítást úgy kényszeríthetjük ki, ha a template kulcsszó után (melyet ez esetben 
nem követ c jel) deklaráljuk a kívánt egyedi célú változatot: 


template class vectorsint:; // osztály 
template intő vectorsint:::operatort/[GnW9; // tag 
template int convertzint, doublex(double); // függvény 


Tehát egy sablon deklarációja a templatecx kifejezéssel kezdődik, míg egy példányosítási ké- 
relmet a template kulcsszóval fejezünk ki. Figyeljük meg, hogy a template szó után a teljes 
deklaráció szerepel, nem elég csak a példányosítani kívánt nevet leírnunk: 


template vectorsint:::operatort]; // formai hiba 
template convertsint, doublex; // formai hiba 


A függvényparaméterekből levezethető sablonparaméterek ugyanúgy elhagyhatók, mint 
a sablon függvények meghívásakor (413.3. DD: 


template int convertxint, doublex(double); // rendben (felesleges) 
template int convertsint:(double); // rendben 


Amikor egy sablon osztályt így példányosítunk, a tagfüggvényekből is létrejön egy példány. 
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Az explicit példányosítás különböző ellenőrzések elvégzésére is felhasználható (§13.6.29: 


templatexcilass T- class Calls foo ( 


void constraints(T t) ( foo(D; ) // minden konstruktorból meghívandó 

eds 
]: 
template class Calls foosint:; // hiba: foo(int) nem meghatározott 
template Calls foosShape"2::constraintsO; // hiba: foo(Shape") nem meghatározott 


A példányosítási kérelmek hatása az összeszerkesztési időre és az újrafordítás hatékonysá- 
gára nézve jelentős lehet. Arra is láttam már példát, hogy a sablon-példányosítások egyet- 
len fordítási egységbe való összefogásával a fordítási időt néhány óráról néhány percre si- 
került csökkenteni. 


Hibát jelent, ha ugyanarra az egyedi célú változatra két meghatározás is van. Nem számít, 
hogy ezek felhasználó által megadottak (413.5), automatikusan létrehozottak (4C.13.79, 
vagy példányosítási kérelemmel készültek. A fordító nem köteles észrevenni a többszörös 
példányosítást, ha az egyes változatok különböző fordítási egységekben fordulnak elő. Ez 
lehetővé teszi a felesleges példányosítások elegáns elkerülését, így megszabadulhatunk 
azoktól a problémáktól, melyek a több könyvtárt használó programokban az explicit pél- 
dányosításból származhatnak (§C.13.79. A szabvány azonban nem követeli meg, hogy 
a megvalósítások , elegánsak" legyenek. A , kevésbé elegáns" megvalósítások használóinak 
érdemes elkerülniük a többszörös példányosítást. Ha ezt a tanácsot mégsem fogadjuk meg, 
programunk - a legrosszabb esetben — nem fog futni, de a programban nem következik be 
rejtett változás. 


A nyelv nem követeli meg, hogy a felhasználók explicit példányosítást használjanak. Ez 
csupán olyan optimalizációs lehetőség, mellyel saját kezűleg szabályozhatjuk a fordítás és 
összeszerkesztés menetét (4C.13.7). 


C.14. Tanácsok 


[1] A technikai részletek helyett összpontosítsunk a programfejlesztés egészére. 
4C.1. 
[2] A szabvány szigorú betartása sem garantálja a hordozhatóságot. §4C.2. 


[3] Kerüljük a nem meghatározott helyzeteket (a nyelvi bővítésekben is). §C.2. 
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[4] 


[5] 


[6] 


[7] 


[8] 
[91] 


[10] 
[11] 
[12] 
[13] 
[14] 
[15] 
[16] 


[17] 
[18] 


[19] 


[20] 


[21] 


[22] 
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Legyünk tisztában a megvalósítás-függő szolgáltatásokkal. 4C.32. 

At, [1], I és ! jelek helyett csak akkor használjunk kulcsszavakat és digráf je- 
leket, ha ezek nem elérhetőek az adott rendszerben; trigráf karaktereket pedig 
csak akkor, ha a V sem állítható elő gépünkön. §C.3.1. 

Az egyszerű adatközlés érdekében a programok leírására használjuk az ANSI 
karaktereket. §C.3.3. 

A karakterek számmal jelölése helyett lehetőleg használjuk vezérlőkarakter 
megfelelőiket. §C.3.2. 

Soha ne használjuk ki a char típus előjelességét vagy előjel nélküliségét. §C.3.4. 
Ha kétségeink vannak egy egész literál típusával kapcsolatban, használjunk 
utótagokat. §C.4. 

Kerüljük az értékvesztő automatikus átalakításokat. §C.6. 

Használjuk a vector osztályt a beépített tömbök helyett. §C.7. 

Kerüljük a union típus használatát. §C.8.2. 

A nem általunk készített szerkezetek leírására használjunk mezőket. §C.8.1. 
Figyeljünk a különböző memóriakezelési stílusok előnyeire és hátrányaira. $C.9. 
Ne , szennyezzük be" a globális névteret. §C.10.1. 

Ha nem típusra, hanem önálló hatókörre (modulra) van szükségünk, osztályok 
helyett használjunk névtereket. §C.10.3. 

Sablon osztályokban is megadhatunk static tagokat. §C.13.1. 

Ha egy sablonparaméter tagtípusaira van szükségünk, az egyértelműség érdeké- 
ben használjuk a tybename kulcsszót. §C.13.5. 

Ha sablonparaméterekkel való kifejezett minősítésre van szükségünk, használ- 
juk a template kulcsszót a sablon osztály tagjainak egyértelmű megadásához. 
§C.13.6. 

A sablon meghatározását úgy fogalmazzuk meg, hogy a lehető legkevesebbet 
használjuk fel a példányosítási környezetből. 4C.13.8. 

Ha egy sablon példányosítása túl sokáig tart, esetleg érdemes explicit példányo- 
sítást alkalmaznunk. §C.13.10. 

Ha a fordítás sorrendjének pontosan megjósolhatónak kell lennie, explicit pél- 
dányosításra lehet szükség. §C.13.10. 


Helyi sajátosságok 


, Ha Rómában jársz, tégy úgy, mint a rómaiak." 


A kulturális eltérések kezelése e A locale osztály s Nevesített lokálok e Lokálok létreho- 
zása s Lokálok másolása és összehasonlítása s A g/obalO és classicO lokálok s Karakter- 
láncok összehasonlítása e A facet osztály e Jellemzők elérése a lokálokban e Egyszerű fel- 
használói facet-ek s Szabványos facet-ek s Karakterláncok összehasonlítása e Numerikus 
[/O s Pénz [/D s Dátum és idő [/O s Alacsonyszintű időműveletek e Egy Date osztály " 
A karakterek osztályozása s Karakterkód-átalakítások e Üzenetkatalógusok s Tanácsok e 
Gyakorlatok 


D.1. A kulturális eltérések kezelése 


A locale Cdokáb a helyi sajátosságokat jelképező objektum. Olyan kulturális jellemzőket tar- 
talmaz, mint a karakterek tárolásának és a karakterláncok összehasonlításának módja, illet- 
ve a számok megjelenési formája a kimeneten. A helyi sajátosságok köre bővíthető: a prog- 
ramozó a lokálhoz további olyan jellemzőket (/acet; , arculat", szempont) adhat, amelyeket 
a standard könyvtár nem támogat közvetlenül. Ilyenek például az irányítószámok vagy a te- 
lefonszámok. A locale elsődleges szerepe a standard könyvtárban a kimeneti adatfolyam- 
ban Costream) levő adatok megjelenítési formájának, illetve a bemeneti adatfolyamok 


Cistream) által elfogadott információ formátumának szabályozása. 
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A §21.7 pontban már tárgyaltuk, hogyan módosíthatjuk az adatfolyamok formátumát; ez 
a függelék azt írja le, hogy építhető fel jellemzőkből (jaceD egy locale, illetve azt magyaráz- 
za el, hogyan befolyásolja a lokál az adatfolyamot. Ismerteti a facet-ek definiálásának mód- 
ját is, felsorolja a szabványos jellemzőket, amelyekkel az adatfolyamok tulajdonságai beál- 
líthatók és módszereket mutat be mindezek létrehozására és használatára. Az adat- és 
időábrázolást segítő standard könyvtárbeli eszközöket a dátumok be- és kivitelének tárgya- 
lásakor mutatjuk be. 


A lokálok és jellemzők tárgyalását a következő részekre bontottam: 


§D.1 A kulturális eltérések lokálokkal való ábrázolása mögött rejlő alapgondo- 
latok bemutatása 

§D.2 A locale osztály 

§D.3 A facet osztály 


§D.4 A szabványos jellemzők áttekintése és részletes ismertetése: 
§D.4.1 Karakterláncok összehasonlítása 
$D.4.2 Számértékek bevitele és kivitele 
$D.4.3 Pénzértékek bevitele és kivitele 
§D.4.4 Dátum és idő bevitele és kivitele 


§D.4.5 A karakterek osztályozása 
§D.4.6 Karakterkód-konverziók 
SD.4.7 Üzenetkatalógusok 


A locale nem a C-t fogalma, a legtöbb operációs rendszerben és felhasználói környezet- 
ben létezik. A helyi sajátosságokon ( területi beállításokon") — elvileg — az adott rendszer- 
ben megtalálható valamennyi program osztozik, függetlenül attól, hogy a programok mi- 
lyen programnyelven íródtak. Ezért a C-t4-4 standard könyvtárának /ocale-jét úgy 
tekinthetjük, mint amelynek segítségévek a programok szabványos és , hordozható" módon 
férhetnek hozzá olyan adatokhoz, melyek ábrázolása a különböző rendszerekben jelentő- 
sen eltér. Így a C-t locale közös felületet biztosít azon rendszeradatok eléréséhez, melye- 
ket az egyes rendszerek más és más módon tárolnak. 


D.1.1. A kulturális eltérések programozása 


Képzeljük el, hogy olyan programot írunk, melyet sok országban fognak használni. Azt, 


hogy a programot olyan stílusban írjuk meg, ami ezt lehetővé teszi, gyakran hívják nemzet- 


közi támogatásnak ( internacionalizáció"; ez kihangsúlyozza, hogy a programot több or- 
szágban használják) vagy honosításnak ( lokalizációnak", kihangsúlyozva a program helyi 
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viszonyokhoz igazítását). A program által kezelt adatok némelyike — a szokásoknak megfe- 
lelően — különbözőképpen jelenik meg az egyes országokban. A problémát úgy kezelhet- 
jük, hogy a bemeneti/kimeneti eljárások megírásánál ezt figyelembe vesszük: 


void print date(const Datekg d) // kiírás a megfelelő formában 


( 


switch(where am D // felhasználói jelzőérték 


f 

case DK: //pl. 7. marts 1999 
cout CZ d.dayO cc ". " cz dk monthl[d.monthOJ cz " " cz d.yearO; 
break; 

case UK: //pl.7/3/1999 
cout CZ d.dayO c£ "/" cz d.monthO cz "/" cz d.yearO; 
break; 

case US:  // pl. 377/1999 
cout c£ d.monthO cca !" cz d.dayO cz (" cz d.yearO; 
break; 

Moi 

J 


Egy ilyen kóddal a feladat megoldható, de a kód elég csúnya és csak következetes haszná- 
latával biztosíthatjuk, hogy minden kimenet megfelelően igazodjon a helyi szokásokhoz. 
Ami még ennél is rosszabb: ha újabb dátumformátummal szeretnénk kiegészíteni, módosí- 
tanunk kell a kódot. Felmerülhet az ötlet, hogy a problémát egy osztályhierarchia létreho- 
zásával oldjuk meg (412.2.4). A Date-ben tárolt adatok azonban függetlenek a megjelenítés 
módjától, így nem Date típusok (például US date, UK date, és JP date) rendszerét kell lét- 
rehoznunk, hanem a dátumok megjelenítésére kell megadnunk többféle módszert (mond- 
juk amerikai, brit és japán stílusú kimenetet). Lásd még: §D.4.4.5. 


Az ,engedjük meg a felhasználónak, hogy bemeneti/kimeneti függvényeket írjon és kezel- 
jék azok a helyi sajátosságokat" megközelítésnek is vannak buktatói: 


1. Egy rendszerfejlesztő programozó nem tudja könnyen, más rendszerre átültet- 
hető módon és hatékonyan módosítani a beépített típusok megjelenését a stan- 
dard könyvtár segítsége nélkül. 

2. Egy nagy programban nem mindig lehet az összes [/D műveletet (és minden 
olyan műveletet, amely a helyi sajátosságokhoz igazítva készít elő adatot [/O- 
hoz) megtalálni. 

3. A programot néha nem igazíthatjuk az új szabályokhoz - és még ha lehetséges 
is lenne, jobban szeretnénk egy olyan megoldást, amely nem igényel újraírást. 
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4. Pazarlás lenne minden felhasználóval megterveztetni és elkészíttetni az eltérő 
helyi sajátosságokat kezelő programelemeket. 

5. A különböző programozók különféleképpen kezelik a kulturális eltéréseket, 
ezért a valójában ugyanazokkal az adatokkal dolgozó programok is különbözni 
fognak, noha alapvetően azonosnak kellene lenniük. Így azoknak a programo- 
zóknak, akik több forrásfájlban lévő kódot , tartanak karban", többfajta progra- 
mozási megközelítést kell megtanulniuk, ami fárasztó és hibalehetőséget rejt 
magában. 


Következésképpen a standard könyvtár a helyi sajátosságok kezeléséhez bővíthető eljárás- 
gyűjteményt kínál. Az iostream könyvtár (421.7) mind a beépített, mind a felhasználói típu- 
sok kezeléséhez ezekre az eljárásokra támaszkodik. Vegyünk például egy egyszerű ciklust, 
amely mérések sorozatát vagy tranzakciók egy halmazát ábrázoló (Date, double) párokat 
másol: 


void cpy(istreamé is, ostream£t os) // (Date, double) adatfolyamot másol 


t 
Date d; 


double volume; 
while (is 32 d 553 volume) os c d cz 


c£ volume cz 


Egy valódi program természetesen csinálna valamit a rekordokkal és egy kicsit jobban tö- 
rődne a hibakezeléssel is. 


Hogyan készíthetünk ebből egy olyan programot, amely a francia szokásoknak megfelelő 
fájlt olvas be (ahol — a magyarhoz hasonlóan — vesszőt használnak a , tizedespont" jelölésé- 
re a lebegőpontos számokban; például a 72, 5 jelentése tizenkettő és fél) és az amerikai for- 
mának megfelelően írja azt ki? Lokálok és [/D műveletek meghatározásával a cpyO-t hasz- 


nálhatjuk az átalakításra: 


void f(istreamk fin, ostreamdt fout, istreamk fin2, ostreamk fout2) 


( 
Jfin.iimbue(locale("en US"); // amerikai angol 
foutimbuetdocaleC fr"); // francia 
cby(fin fouD; // amerikai angol olvasás, francia írás 
Jfin2.imbuedlocaleC fr"; // francia 
fout2.imbuedlocaleC"en US"); // amerikai angol 


cby(fin2 four; // francia olvasás, amerikai angol írás 
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Ha adottak a következő adatfolyamok, 


Apr 12, 1999 1000.3 
Apr 13, 1999 345.45 
Apr 14, 1999 9688.321 


3 juillet 1950 10,3 
3 juillet 1951 13445 
3 juillet 1952 67,9 


a program a következőt fogja kiírni: 


12 avril 1999 1000,3 
13 auvril 1999 34545 
14 avril 1999 9688,321 


July 3, 1950 10.3 
July 3, 1951 13445 
July 3, 1952 67.9 


A függelék további részének legjavát annak szenteljük, hogy leírjuk, milyen nyelvi tulajdon- 
ságok teszik ezt lehetővé, illetve hogy elmagyarázzuk, hogyan használjuk azokat. Jegyez- 
zük meg, hogy a programozók többségének nem kell részletekbe menően foglalkoznia 
a lokálokkal vagy kifejezetten azokat kezelő kódot írnia. Akik mégis megteszik, azok is leg- 
inkább egy szabványos /ocale-t fognak előkeresni, hogy az adott adatfolyamnak előírják an- 
nak használatát (§21.79. Azok az eljárások azonban, melyekkel a lokálokat létrehozhatjuk és 


használatukat egyszerűvé tehetjük, , saját" programnyelvet alkotnak. 


Ha egy program vagy rendszer sikeres, olyanok is használni fogják, akiknek az igénye és 
ízlése eltér attól, amire az eredeti tervezők és programozók számítottak. A legtöbb sikeres 
programot használni fogják azokban az országokban is, ahol a (természetes) nyelvek és ka- 
rakterkészletek eltérnek az eredeti tervezők és programozók által ismertektől. Egy program 
széleskörű használata a siker jele, ezért a nyelvi és kulturális határok között átvihető prog- 
ramok tervezése és írása a sikerre való felkészülést jelenti. 

A , nemzetközi támogatás" 
objektumok elkészítését meglehetősen bonyolulttá teszik: 


fogalma egyszerű, a gyakorlati megszorítások azonban a locale 


1. A lokálok az olyan helyi sajátosságokat tartalmazzák, mint a dátumok megjele- 
nési formája. A szabályok azonban egy adott kultúrán belül is számos apró és 
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nem rendszerezhető módon eltérhetnek. A helyi szokásoknak semmi közük 
a programnyelvekhez, ezért egy programnyelv nem szabványosíthatja azokat. 

2. A lokáloknak bővíthetőnek kell lenniük, mert nem lehetséges az összes helyi 
sajátosságot felsorolni, amely minden C-t felhasználónak fontos. 

3. A locale objektumokat olyan [/O műveletekben használjuk, melyeknél a futási 
idő igen fontos. 

4. A locale objektumoknak láthatatlannak kell lenniük a legtöbb programozó szá- 
mára, hiszen ők anélkül szeretnék kihasználni a , megfelelő dolgot végző" adat- 
folyam-bemenetet és -kimenetet, hogy pontosan ismernék annak felépítését, 
megvalósítását. 

5. A lokáloknak elérhetőnek kell lenniük azok számára, akik olyan eszközöket ter- 
veznek, amelyek helyi sajátosságoktól függő adatokat kezelnek az adatfolyam 
[/O könyvtár keretein kívül. 


Egy bemeneti és kimeneti műveleteket végző program tervezésekor választanunk kell, 
hogy a kimenet formátumát , szokásos kóddal" vagy locale-ek felhasználásával vezéreljük- 
e. Az előbbi (hagyományos) megközelítés ott célszerű, ahol biztosítani tudjuk, hogy min- 
den bemeneti műveletet könnyen át lehet alakítani a helyi sajátosságoknak megfelelően. 
Ha azonban a beépített típusok megjelenésének kell változnia, ha különböző karakterkész- 
letekre van szükség, vagy ha a bemenetre/kimenetre vonatkozó szabályok halmazai között 
kell választanunk, a locale objektumok használata tűnik ésszerűbbnek. 


A locale objektumok úgynevezett facet-ekből állnak, amelyek az egyes jellemzőket (lebe- 
gőpontos érték kiírásakor használt elválasztó karakter (decimal pointO), §D.4.2), pénzérték 
beolvasásakor használt formátum (moneypunct, §D.4.3) stb.) szabályozzák. A facet egy, 


a locale::facet osztályból származó osztály objektuma (§D.39; leginkább úgy képzelhetjük 
el, hogy a l/ocale facet-ek tárolója (§D.2, §D.3.1. 


D.2. A locale osztály 


A locale osztály és a hozzá tartozó szolgáltatások a c/ocale: fejállományban találhatók: 


class std::locale f 


bublic: 
class facet; // lokáljellemzőket tartalmazó típus, $D.3 
class id; // lokált azonosító típus, §D.3 


typedef int category; // facet-ek csoportosítására szolgáló típus 


D. Helyi sajátosságok 1179 


static const category // a tényleges értékek megvalósításfüggőek 
none - O, 
collate — 1, 
ctype — 1221, 
monetary — 1222, 
numeric - 1223, 
time — 1224, 
messages — 1205, 
all - collate l ctype I monetary I numeric I time I messages; 


localeO throwO; // a globális lokál másolata (§D.2.1 
locale(const localekg x) throwO; // x másolata 
explicit locale(const char? p); // a p nevű lokál másolata (§D.2.1) 


-locale0 throwO; 


locale(const localeg x, const char?" b, category c); . // x másolata, plusz p-beli c facet-ek 
locale(const localek x, const localek y, category c); // x másolata, plusz y-beli c facet-ek 


template class Facet: locale(const localekg x, Facet" fd; // x másolata, plusz az f facet 
template class Facet- locale combine(const localeg x); // "this másolata, 
// plusz az x-beli Facet 


const localek operator-(const localek x) throwO); 


bool operator-—(const localeg ) const; // lokálok összehasonlítása 
bool operator!1—(const localek ) const; 


string nameO const; // az adott lokál neve (§D.2.1 


template cclass Ch, class Tr, class Az // karakterláncok összehasonlítása 
// az adott lokál segítségével 
bool operatorO(const basic stringzCh, Tr, A2£, const basic stringZCh, Tr, A2£) const; 


static locale globalk(const locale);  // a globális lokál beállítása és visszatérés a régivel 
static const localekg classicO; // a "klasszikus" C-stílusú lokál 

Private: 
// ábrázolás 


); 


A locale-ekre úgy gondolhatunk, mint mapcid facet":-ek felületére, vagyis valami olyasmi- 
re, ami lehetővé teszi, hogy egy locale::id segítségével megtaláljuk a megfelelő objektumot, 
amelynek osztálya a locale::facet-ből származik. A locale megvalósítása alatt az e gondolat 


alapján elkészített (hatékony) szerkezeteket értjük. Az elrendezés ilyesmi lesz: 
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collatezchar:: 





locale: 








compare ( ) 
hash ( ) 


fe eepemeteehar 


decimal point ( ) 
truename ( ) 









































Itt a collatezchar: és a numpunciKchar? a standard könyvtár facet-jei (§D.4). Mint mind- 
egyik facet, ezek is a locale::facet-ből származnak. 


A locale-nek szabadon és , olcsón" másolhatónak kell lennie. Következésképpen a /ocale-t 
majdnem mindig úgy valósítják meg, mint egy leírót arra a , szakosított" mapcid facet"2-re, 
amely a szolgáltatások legtöbbjét tartalmazza. A lokál jellemzőinek (a facet-eknek) gyorsan 
elérhetőnek kell lenniük, ezért az egyedi célú mapcid, facet": a tömbökhöz hasonló gyors 
hozzáférést kell, hogy nyújtson. A locale jellemzőinek elérése a use facetcFacet-(loc) jelö- 
léssel történik (lásd §D.3.1-et). 


A standard könyvtár a facet-ek gazdag választékát nyújtja. A programozó ezeket logikai cso- 
portokban kezelheti, mert a szabványos facet-ek kategóriákat alkotnak (pl. numeric és 
collate, §D.4). 


A programozó az egyes kategóriákban levő jellemzőket kicserélheti (§D.4, §D.4.2.19, de 
nem adhat meg új kategóriákat. A , kategória" fogalma csak a standard könyvtárbeli facet- 
ekre vonatkozik, nem terjeszthető ki a felhasználói jellemzőkre. Ezért nem szükséges, hogy 
egy Jacet kategóriába tartozzon és sok felhasználói facet nem is tartozik ilyenbe. 


A lokálokat messze a leggyakrabban az adatfolyamok bemeneti és kimeneti műveletinél 
használjuk, még ha nem is tudunk róla. Minden istream és ostream rendelkezik saját lokál- 
lal. Az adatfolyamok lokálja a folyam létrehozásának pillanatában alapértelmezés szerint 
a globális /ocale (§D.2.1) lesz. A folyam lokálját az inbueO ( megtöltés") művelettel lehet 
beállítani, a locale másolatát pedig a getloc0 függvénnyel kaphatjuk meg (§21.6.3). 
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D.2.1. Nevesített lokálok 


A lokálok másik /ocale-ből és jellemzőkből hozhatók létre. A legegyszerűbb egy már léte- 
ző locale lemásolása: 


locale locO; // az érvényes globális lokál másolata (§D.2.3) 
locale loc1 — locale; // az érvényes globális lokál másolata (fD.2.3) 
locale loc2C"; // a felhasználó által előnyben részesített lokál 
másolata 

locale loczCC"); // a "C" lokál másolata 

locale loc4 - locale::classicO; // a "C" lokál másolata 

locale locS(POSIX JJ; // az adott fejlesztőkörnyezet által meghatározott 


// "POSIX" lokál másolata 


A locale( C") jelentését a szabvány , klasszikus C lokálként" határozza meg; ebben a könyv- 
ben végig ezt a lokált használjuk. A többi /ocale neve a használt C----változattól függ. 


A locale(") a , felhasználó által előnyben részesített" lokál, melyet a program végrehajtási 
környezetében a nyelven kívüli eszközök állítanak be. 


A legtöbb operációs rendszer biztosít valamilyen eszközt a programok , területi beállításai- 
nak" megadására. A beállításra legtöbbször akkor kerül sor, amikor a felhasználó először ta- 
lálkozik a rendszerrel. Egy olyan gépen például, ahol a rendszer alapértelmezett nyelveként 
az argentin spanyolt adták meg, a locale(") valószínűleg a localelC"es AR"-t jelenti. 
Az egyik rendszerem gyors ellenőrzése 51 megjegyezhető névvel rendelkező lokált muta- 
tott ki (például POSZX, de, en UK, en US, es, es AR, fr, sv, da, pl, és iso 8859 D. A POSIX 
által ajánlott formátum: kisbetűs nyelvnév, amit nagybetűs országnév követ (ez nem köte- 
lező), valamint egy kódjelző (ez sem kötelező); például ip /P.jit. Ezek a nevek azonban 
nem szabványosítottak a különböző platformok között. Egy másik rendszerben egyéb 
locale nevek mellett a következőket találtam: g, uk, us, s, fr, sw, és da. A Ct4t szabvány nem 
adja meg az országok és nyelvek /ocale-jét, bár az egyes platformokra létezhetnek szabvá- 
nyok. Következésképpen, ha a programozó nevesített lokálokat akar használni, a rendszer 


Általában célszerű elkerülni a lokálneveket jelző karakterláncok programszövegbe ágyazá- 
sát. A fájlnevek és , rendszerállandók" programban való szerepeltetése korlátozza a prog- 
ram hordozhatóságát, a programot új környezetbe beilleszteni kívánó programozó pedig 
gyakran arra kényszerül, hogy megkeresse ezeket az értékeket, hogy módosíthassa azokat. 
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A lokálnevek megemlítése is hasonló kellemetlen következményekkel jár. Jobb, ha a loká- 
lokat kivesszük a program végrehajtási környezetéből (például a localeC") telhasználásá- 
val) vagy a programra bízzuk, hogy a tapasztaltabb felhasználóktól a lokál meghatározását 
kérje, mondjuk egy karakterlánc bekérésével: 


void user. set locale(const stringdt guestion string) 


( 
cout ££ guestion string; // pl. "Ha más lokált kíván használni, adja meg a nevét" 
string s; 
cin 535 s; 
locale::global(locale(s.c strO)); // a felhasználó által megadott globális lokál beállítása 


A kezdő felhasználók számára általában jobb, ha lehetővé tesszük, hogy listából választhassa- 
nak. Az ezt kezelő eljárásnak viszont tudnia kell, hol és hogyan tárolja a rendszer a lokálokat. 


Ha a paraméterként megadott karakterlánc nem definiált /ocale-re hivatkozik, a konstruktor 
runtime error kivételt vált ki (414.109: 


void set loc(iocalek loc, const char?" name) 
íry 
( 


loc - localelrname); 
) 
catch (runtime error) (f 
cerr Sz "A W" c£ name cz MW lokál nem definiált.Nn"; 


ZATA 


Ha a locale nevesített, a name visszaadja annak nevét, ha nem, a string(""")-gal tér vissza. 
A név elsősorban arra való, hogy hivatkozhassunk a végrehajtási környezetben tárolt loká- 
lokra, de a hibakeresésben is segíthet: 


void print locale names(const localekgk my loc) 

( 
cout c£ "name of current global locale: " cZ localeO.nameO cz Ant; 
cout c£ "name of classic C locale: " Sz locale::classic0.nameO cz Mn; 
cout ££ "name of "user ss preferred locale: " cz localeC").nameO cz Nn; 
cout c£ "name of my locale: " cz my loc.nameO zzz Mn; 


Az alapértelmezett szring( """)-tól eltérő, de azonos nevű lokálok összehasonlításkor egyen- 
értékűnek minősülnek, az —— vagy /- operátorokkal azonban az összehasonlítás közvetle- 
nebb módon is elvégezhető. 
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A névvel rendelkező /ocale-ek másolatai ugyanazt a nevet kapják, mint az eredeti /ocale (ha 
annak van neve), így azonos néven több /ocale is szerepelhet. Ez logikus, mert a lokálok 
nem módosíthatók, így ezen objektumok mindegyike a helyi sajátosságok ugyanazon hal- 
mazát írja le. 


A locale(doc, "Foo", cat) hívás a loc-hoz hasonló lokált hoz létre, de annak jellemzőit (a facet- 
eket) a locale( Foo") cat kategóriájából veszi. Az eredményül kapott lokálnak kizárólag ak- 
kor lesz neve, ha a /oc-nak is volt. A szabvány nem határozza meg pontosan, milyen nevet 
kap az új locale, de feltehető, hogy különbözni fog a /oc-étól. A legegyszerűbb, ha a nevet 
a loc nevéből és a "Foo"-ból építjük fel. Például ha a loc neve en UK, az új lokál neve 
"en UK:Foo" lesz. 


Az új lokálok elnevezésére vonatkozó szabályok a következőképpen foglalhatók össze: 











Lokál Név 

locale Foo") "Foo" 

locale(loc) loc. nameO 

locale(loc, "Foo", cat) Új név, ha a loc-nak van neve; egyébként 
string 8") 

locale(loc, loc2, cat) Új név, ha a loc-nak és a loc2-nek is van 
neve; egyébként string(") 

locale(loc, Facet) string( 8") 

loc.combine(loc2) string 8") 











A programozó az újonnan létrehozott /ocale-ek neveként nem adhat meg C stílusú karak- 
terláncot. A neveket a program végrehajtási környezete határozza meg vagy a locale 
konstruktorok építik fel azokat a nevek párosításából. 


D.2.1.1. Új lokálok létrehozása 


Új locale objektumot úgy készíthetünk, hogy veszünk egy már létező /ocale-t és ehhez jel- 
lemzőket adunk vagy kicserélünk benne néhányat. Az új l/ocale-ek jellemzően egy már lé- 


tező locale kissé eltérő változatai: 
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void Kconst localek loc, const My money io? mio) // A SD.4.3.1-ben leírt 


"My money io" 


( 
locale loci(locale("POSIX"), loc, locale::monetary); /7 A loc-beli bénzformátum- 


// jellemzők használata 
locale loc2 - locale(dlocale::classicO, mio); // a klasszikus, plusz "mio" 


Zs 


Itt /oc1 a POSIX lokál másolata, amit úgy módosítottunk, hogy a loc pénzformátum-jellem- 
zőit használja (§D.4.3). Ehhez hasonlóan, loc2 a Clokál másolata, amely a My money io-t 
használja (§D.4.3.15. Ha a Facet?" paraméter (itt a My money io) értéke 0, az eredményül 
kapott lokál egyszerűen a locale paraméter másolata lesz. 


Ha a következőt írjuk, 


locale(const localekg x, Facet" f/; 


az fparaméternek egy meghatározott facet típust kell jelölnie. Egy egyszerű facet" nem ele- 
gendő: 


void g(const locale::facet? miol, const My money io? mio2) 


( 


locale loc3 - locale(docale::classicO, mio 1; // hiba: a facet típusa nem ismert 
locale loc4 — locale(locale::classicO, mio2); — // rendben: a facet típusa ismert 


Mei 


Ennek az az oka, hogy a locale a Facet" paraméter típusát használja arra, hogy fordítási idő- 
ben megállapítsa a facet típusát. Pontosabban, a locale megvalósítása a jellemző azonosító- 
ját, a facet::id-t (§D.3.3) használja, hogy a jellemzőt megtalálja a lokálban (§D.3.1. 


Jegyezzük meg, hogy a 


template cclass Facet: locale(const localekg x, Facet" f); 


konstruktor a nyelv által nyújtott egyetlen eljárás a programozó számára, hogy facet-eket 
adhasson meg, melyeket egy /ocale-en keresztül használni lehet. Az egyéb lokálokat a meg- 
valósító programozóknak kell megadniuk, nevesített /ocale-ek formájában (§D.2.1), melye- 
ket a program végrehajtási környezetéből lehet megszerezni. Ha a programozó érti az erre 
használatos — a fejlesztőkörnyezettől függő — eljárást, a meglevő lokálok körét újakkal bő- 
vítheti (SD.6[11,12D. 
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A lokálok konstruktorainak halmazát úgy tervezték, hogy minden jellemző típusa megálla- 
pítható legyen, vagy típuslevezetés útján (a Facet sablonparaméter típusából), vagy azért, 
mert egy másik lokálból származik, amely ismerte a jellemző típusát. A category paraméter 
megadásával a facet-ek típusát közvetett módon is meghatározhatjuk, hiszen a lokálok isme- 


rik a kategóriákban lévő jellemzők típusát. Ebből következik, hogy a locale osztály nyomon 
követheti a facet-ek típusát, így azokat különösebb többletterhelés nélkül módosíthatja is. 


A lokál a facet típusok azonosítására a locale::id tagtípust használja (§D.39. 


Néha hasznos lehet olyan lokált létrehozni, amely egy másik lokál másolata, de az egyik jel- 
lemzője egy harmadik lokálból származik. A combineO sablon tagfüggvény erre való: 


void Kconst localek loc, const localekg loc2) 


( 


locale loc3 - loc.combinez My money io 2(loc29; 
VAS 
VA 


Az eredményül kapott /oc3 úgy viselkedik, mint a /oc, de a pénzformátumot a /oc2-ben le- 
vő My money io (§D.4.3.1) másolata alapján állítja be. Ha a loc2 nem rendelkezik 
a My money io-val, hogy átadhassa azt az új lokálnak, a combineO runtime error-t 
(§14.10) vált ki. A combineO eredményeként kapott lokál nem nevesített. 


D.2.2. Lokálok másolása és összehasonlítása 


A lokálok kezdeti vagy egyszerű értékadással másolhatók: 


void swap(localek x, localeg y) — // ugyanaz, mint az std::swapO 


( 


locale temp — x; 


xX-y; 
) —- lemp; 


j 
A másolat az eredetivel egyenértékű, de független, önálló objektum: 


void f(docale? my locale) 


( 


locale loc -— locale::classicO; // "C" lokál 


if doc !- locale::classicO) f 
cerr 22 "Hiba a megvalósításban: értesítse a készítőt Nn"; 
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exit( 1); 
) 


if (kloc "- klocale::classicO) cout cz "Nem meglepő: a címek különböznek NM"; 
locale loc2 - localetloc, my locale, locale::numeric); 


if doc —— loc2) f 
cout cz "a classicO hasonló facet-jében levőkkel Nn"; 
VAS 


) 
ll sésá 


Ha a my locale rendelkezik olyan jellemzővel, amely a classicO lokál szabványos 


numpuncischar7-jától eltérően adja meg a számok elválasztó írásjeleit (my numpuncicchar?), 
az eredményül kapott lokálok a következőképpen lesznek ábrázolhatók: 


loc: 


collatezchar:: 





compare ( ) 


loc2: 





hash ( ) MOZlTEz 

















numpuncirchar?: 











decimal point ( ) 
curr. symbol ( ) 











my numpunciáchar:: 





decimal point ( ) 
curr. symbol ( ) 
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A locale objektumok nem módosíthatók, műveleteik viszont lehetővé teszik új lokálok lét- 
rehozását a már meglevőkből. A létrehozás utáni módosítás tiltása (a lokál ,nem változé- 
kony", inmutable természete) alapvető fontosságú a futási idejű hatékonyság érdekében, 
ez teszi ugyanis lehetővé a felhasználó számára, hogy meghívja a facet-ek virtuális függvé- 
nyeit és tárolja a visszaadott értékeket. A bemeneti adatfolyamok például anélkül tudhatják, 
milyen karakter használatos a tizedesvessző (pontosabban , tizedespont") jelzésére, illetve 
anélkül ismerhetik a true ábrázolását, hogy minden egyes alkalommal meghívnák — szám 
beolvasásakor — a decimal pointO függvényt vagy — logikai érték beolvasásakor — 
a truenameO-et (§D.4.2). Csak az imbueO meghívása az adatfolyamra (421.6.3) okozhatja, 


hogy ezek a hívások különböző értékeket adjanak vissza. 


D.2.3. A global() és classic() lokálok 


A programban érvényben levő lokál másolatát a JlocaleO adja vissza, a locale::global(x) pe- 
dig x-re állítja azt. Az érvényes lokált gyakran , globális lokálnak" hívják, utalva arra, hogy 
valószínűleg globális (vagy statikus) objektum. 


Az adatfolyamok létrehozásukkor automatikusan , feltöltődnek" (imbue; §21.1, §21.6.3) 
a globális lokállal, vagyis a focale0 másolatával, ami először mindig a szabványos C 
locale::classicO. 


A locale::globalO statikus tagfüggvény megengedi, hogy a programozó meghatározza, me- 


lyik lokál legyen globális. Az előző másolatát a g/obal0 függvény adja vissza; ennek segít- 
ségével a felhasználó visszaállíthatja az eredeti globális lokált: 


void Kconst localek my loc) 


( 
ifstream fin1(some name); // fin1 feltöltése a globális lokállal 
localek old global - locale::global(rmy loc); // új globális lokál beállítása 
ifstream fin2(some other. name); // fin2 feltöltése a my loc lokállal 
2 ate 
locale::gliobakold globaD; // a régi globális lokál visszaállítása 
J 


Ha az x lokál rendelkezik névvel, a Jocale::global(x) szintén a C globális lokált állítja be. Eb- 
ből következik, hogy egy vegyes (C és C-4--) programban egységesen és következetesen ke- 
zelhetjük a lokált, ha meghívjuk a C standard könyvtárának valamelyik lokálfüggvényét. 


Ha az xlokálnak nincs neve, akkor nem meghatározható, hogy a locale::global(x) befolyá- 
solja-e a C globális lokált, vagyis a Cst programok nem képesek megbízhatóan Cés , hor- 
dozható módon") átállítani a C lokált egy olyan lokálra, amely nem a végrehajtási környe- 
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zetből való. Nincs szabványos mód arra sem, hogy egy C program beállíthassa a C4-4 glo- 
bális lokált (kivéve ha meghív egy C4- függvényt, ami ezt megteszi), ezért a hibák elkerü- 


lése érdekében a vegyes programokban nem célszerű a g/lobalO-tól eltérő C globális lokált 
használni. 


A globális lokál beállítása nincs hatással a már létező [/D adatfolyamokra; azok ugyanazt 
a lokált fogják használni, amivel eredetileg feltöltődtek. A /in1-re például nem hat a globá- 
lis lokál módosítása, de a fin2-t a művelet a my loc-kal tölti fel. 


A globális lokál módosításával ugyanaz a probléma, mint a globális adatokat megváltozta- 
tó egyéb eljárásokkal: lényegében nem tudható, mire van hatással a változtatás. Ezért a leg- 
jobb, ha a g/obalO-t a lehető legkevesebbszer használjuk és a módosítást olyan kódrészle- 
tekre korlátozzuk, ahol annak hatása pontosan nyomon követhető. Szerencsére ezt segíti 
az a lehetőség, hogy az adatftolyamokat meghatározott lokálokkal tölthetjük meg (imbue, 
§21.6.3). Azért vigyázzunk: ha a programban elszórva számos explicit /ocale- és facet-keze- 
lő kód található, a program nehezen lesz fenntartható és módosítható. 


D.2.4. Karakterláncok összehasonlítása 


A lokálokat többnyire arra használjuk, hogy összehasonlítsunk két karakterláncot egy 
locale alapján. Ezt a műveletet maga a locale nyújtja, a felhasználóknak nem kell saját össze- 
hasonlító eljárást írniuk a collate jellemzőből (§D.4.1). Az eljárás a lokál oberatorO O össze- 
hasonlító függvénye, így közvetlenül használható predikátumként (418.4.29: 


void fvectorsstring:£ v, const localek my locale) 


( 
sort(v.beginO, v.endO); // rendezés a globális lokál szerint 
Me 
sort(v.beginO), v.endO, my locale); // rendezés a my. locale szabályai szerint 
HZARES 


Alapértelmezés szerint a standard könyvtárbeli sort a c műveletet alkalmazza a karakte- 
rek számértékére, hogy eldöntse a rendezési sorrendet (§18.7, §18.6.3.1). 


Jegyezzük meg, hogy a lokálok basic string-eket hasonlítanak össze, nem C stílusúakat. 
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D.3. Jellemzők 


A jellemzők (facet-ek) a lokál facet tagosztályából származtatott osztályok objektumai: 


class std::locale::facet f 


brotected: 
explicit facet(size tr — 09; // "r--0": a lokál szabályozza a facet élettartamát 
virtual -facetO; // figyelem: védett destruktor 
brivate: 
Jacet(const facetk ); // nem meghatározott 
void operator-(const facetk ); // nem meghatározott 
// ábrázolás 
j; 


A másoló műveletek privát tagok és szándékosan nincsenek definiálva, hogy a másolást 
megakadályozzák (§11.2.29. 


A facet osztály bázisosztály szerepet tölt be, nyilvános függvénye nincs. Konstruktora vé- 
dett, hogy megakadályozza az , egyszerű facet objektumok létrehozását, destruktora pedig 
virtuális, hogy biztosítsa a származott osztálybeli objektumok megfelelő megsemmisítését. 


A jellemzők kezelését a lokálok elvileg mutatókon keresztül végzik. A /acet 
konstruktorának 0 értékű paramétere azt jelenti, hogy a lokálnak törölnie kell az adott jel- 
lemzőt, ha már nincs rá hivatkozás. Ezzel szemben a nem nulla konstruktor-paraméter azt 
biztosítja, hogy a locale sohasem törli a jellemzőt. Ez az a ritka eset, amikor a facet élettar- 
tamát a programozó közvetlenül, nem a lokálon keresztül szabályozza. 
A collate bynamexchar? szabványos facet típusú objektumokat például így hozhatjuk lét- 
re (§D.4.1.1: 


void Kconst stringét s1, const stringk s2) 

f 
// szokásos eset: a O (alapértelmezett?) paraméter azt jelzi, 
// hogy a lokál felel a felszámolásért 
collatezchar:? p - new collate bynamezcharx( pl"; 
locale loc(IocaleO, p); 


// ritka eset: a paraméter értéke 1, tehát a felhasználó felel a felszámolásért 
collatezchar:? g - new collate bynamezchar-( "ge", 1; 


collate bynamezchar: bug1( sw");  /7 hiba: lokális változót nem lehet felszámolni 
collate bynamecchar: bug2("no", 1; // hiba: lokális változót nem lehet felszámolni 


VESE 
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// ag nem törölhető: a collate bynamexchar? destruktora védett 


// nincs "delete p", mert a lokál intézi "p felszámolását 


j 


Azaz a szabványos facet-ek a lokál által kezelt bázisosztályként hasznosak, ritkán kell más 
módon kezelnünk azokat. 

A  bynameO végződésű jellemzők a végrehajtási környezetben található nevesített lokál 
Jacetjei (§D.2.1. 


Minden /facet-nek rendelkeznie kell azonosítóval (id), hogy a lokálban a has facetO és 
use facetO függvényekkel megtalálható legyen (4D.3.1: 


class std::locale::id f 

bublic: 
idO; 

brivate: 
id(const id£ ); // nem definiált 
void operator—(const id£ ); // nem definiált 


// ábrázolás 


J; 


A másoló műveletek privátok és nincsenek kifejtve, hogy a másolást megakadályozzák 
(§11.2.29. 


Az azonosító arra való, hogy a jellemzők számára új felületet adó osztályokban (például 
lásd §D.4.1-e) id típusú statikus tagokat hozhassunk létre. A lokálok eljárásai az id-t hasz- 
nálják a facet-ek azonosítására (4D.2, §D.3.19. Az azonosítók többnyire egy facet-ekre hivat- 
kozó mutatókból álló vektor indexértékei (vagyis mapcid facet":, ami igen hatékony). 


A (származtatott) jellemzőket meghatározó adatokat a származtatott osztály írja le, nem ma- 
ga a facet bázisosztály. Ebből következik, hogy a programozó tetszőleges mennyiségű ada- 
tot használhat a facet fogalmának ábrázolására és korlátozás nélkül módosíthatja azokat. 


Jegyezzük meg, hogy a felhasználói facet-ek minden függvényét const tagként kell megha- 
tározni, mert a facet-eknek állandónak kell lenniük (§D.2.2). 
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D.3.1. Jellemzők elérése a lokálokban 


A lokálok facet-jei a use facet sablon függvényen keresztül érhetők el és a has facet sab- 
lon függvénnyel kérdezhetjük le, hogy a lokál rendelkezik-e egy adott jellemzővel: 


template cclass Facet: bool has facet(const localek ) throwO; 
template class Facet: const Faceik use facet(const localek); // bad cast kivételt válthat 
ki 


Ezekre a függvényekre úgy kell gondolnunk, mintha azok locale paraméterükben keresnék 
Facet sablonparaméterüket. Más megközelítésben a use facet egyfajta típuskényszerítés 
(cas), egy lokál konvertálása egy meghatározott jellemzőre. Ez azért lehetséges, mert 
a locale objektumok egy adott típusú facet-ből csak egy példányt tartalmazhatnak: 


void Kconst localek my locale) 


( 


char c - use faceiZ numpunciáchar: (my. locale).decimal pointO0 //awszabványos 
// facet használata 


list 
if (has facetzEncryprx(my locale)) ( // tartalmaz-e a my locale Encrypt facet-et? 
const Encrypik f - use facetsEncryptx$(my locale); // az Encrypt facet kinyerése 
// a my locale-ból 
const Crypto c -— f.get cryptoO; // az Encrypt facet használata 
VALO 
J 
JV a 


Jegyezzük meg, hogy a use facet egy konstans facet-re való referenciát ad vissza, így az 
eredményt nem adhatjuk értékül egy nem konstans változónak. Ez azért logikus, mert a jel- 
lemzőknek elvileg nem módosíthatóknak kell lenniük és csak consttagokat tartalmazhatnak. 


Ha meghívjuk a use facetcxX-(loc) függvényt és loc nem rendelkezik az X jellemzővel, 
a use facet0 bad cast kivételt vált ki (414.109. A szabványos facet-ek garantáltan hozzáfér- 
hetőek minden locale számára (4D.4), így az ő esetükben nem kell a has facet-et használ- 
nunk, ezekre a use facet nem fog bad cast kivételt kiváltani. 


Hogyan lehetne a use facet és has facet függvényeket megvalósítani? Emlékezzünk, hogy 
egy lokálra úgy gondolhatunk, mintha mapcid facet": lenne (§D.2). Ha a Facet sablonpa- 
raméterként adott egy /acet típus, a has facet vagy use facet a Facet::id-re hivatkozhat és 
ezt használhatja a megfelelő jellemző megkeresésére. A has facetés use facet nagyon egy- 
szerű változata így nézhetne ki: 
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// ál-megvalósítás: képzeljük űgy, hogy a lokál rendelkezik egy facet map-nek nevezett 
// mapgzid facet"2-tel 


template class Facet: bool has facet(const localek loc) throwO 


( 
const locale::facet" f - loc. facet maplFacet::idj[; 
return f ? true : false; 


j 


template cclass Facet: const Facetk use facet(const localedt loc) 


( 
const locale::facet" f - loc. facet maplFacet::idj[; 
if (p) return static castáconst Faceik2C; 


throw bad castO; 


j 


A facet::id használatát úgy is tekinthetjük, mint a fordítási idejű többalakúság (parametrikus 
polimorfizmus) egy formáját. A dynamic casta use facet-hez hasonló eredményt adna, de 
az utóbbi sokkal hatékonyabb, mert kevésbé általános. 


Az id valójában inkább egy felületet és viselkedést azonosít, mint osztályt. Azaz ha két fa- 
cet osztálynak pontosan ugyanaz a felülete és (a locale szempontjából) ugyanaz a szerepük, 
akkor ugyanaz az id kell, hogy azonosítsa őket. A  collatezchar: és 
a  collate bynamecchar: például felcserélhető egy lokálban, így mindkettőt 
a collatezchar?::id azonosítja (§D.4.1). 


Ha egy jellemzőnek új felületet adunk — mint az /0-ben az Encrypt-nek -, definiálnunk kell 
számára az azonosítót (lásd §D.3.2-t és §D.4.1-et). 


D.3.2. Egyszerű felhasználói facet-ek 


A standard könyvtár a kulturális eltérések leglényegesebb területeihez — mint a karakter- 
készletek kezelése és a számok be- és kivitele — szabványos /acet-eket nyújt. Ahhoz, hogy 
az általuk nyújtott szolgáltatásokat a széles körben használatos típusok bonyolultságától és 
a velük járó hatékonysági problémáktól elkülönítve vizsgálhassuk, hadd mutassak be elő- 
ször egy egyszerű felhasználói típusra vonatkozó facet-et: 


enum Season ( tavasz, nyár, ősz, tél ); // évszakok 
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Ez volt a legegyszerűbb felhasználói típus, ami éppen eszembe jutott. Az itt felvázolt [/O kis 
módosításokkal a legtöbb egyszerű felhasználói típus esetében felhasználható. 


class Season io : public locale::facet f 
bublic: 
Season io(int i — 0) : locale::facet(i) ( ; 


-Season i00íf)  / lehetővé teszi a Season io objektumok felszámolását (fD.3) 


// x ábrázolása karakterláncként 
virtual const stringít to str(Season x) const — O; 


// az s karakterláncnak megfelelő évszak elhelyezése x-be: 
virtual bool from str(const string s, Seasonkg x) const — O; 


static locale::id id; // facet-azonosító objektum (fD.2, $D.3, SD.3.1 
J; 


locale::id Season io::id; // az azonosító objektum meghatározása 


Az egyszerűség kedvéért a facet csak a chartípust használó megvalósításokra korlátozódik. 
A Season io osztály általános, elvont felületet nyújt minden Season io facet számára. 


Ha a Season be- és kimenetét egy adott lokálra szeretnénk definiálni, a Season io-ból szár- 
maztatunk egy osztályt, amelyben megfelelően kifejtjük a to strO és from strO függvénye- 
ket. 


A Season értékét könnyű kiírni. Ha az adatfolyam rendelkezik Season io jellemzővel, azt 
használva az értéket karakterlánccá alakíthatjuk, ha nem, kiírhatjuk a Season egész értékét: 


ostreamk operatorsgostreamd s, Season x) 


t 
const localeg loc - s.getlocO; — // az adatfolyam lokáljának kinyerése (§21.7.1 


if (has facetsSeason io:(loc)) return s 22 use facetcSeason ior(locC).to St(x); 
return s 22 int(x); 


J 


Észrevehetjük, hogy a cc műveletet úgy definiáltuk, hogy más típusokra hívtuk meg a c€ 
t. Ennek számos előnye van: egyszerűbb a cc-t használnunk, mint a kimeneti adatfolyam 
átmeneti táraihoz közvetlenül hozzáférnünk, a cc műveletet kifejezetten a lokálhoz igazít- 
hatjuk és a művelet hibakezelést is biztosít. A szabványos facet-ek a legnagyobb hatékony- 
ság és rugalmasság elérése érdekében többnyire közvetlenül az adatfolyam átmeneti tárát 
kezelik (§D.4.2.2, §D.4.2.3), de sok felhasználói típus esetében nincs szükség arra, hogy 
a streambuf absztrakciós szintjére süllyedjünk. 
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Ahogy lenni szokott, a bemenet kezelése némileg bonyolultabb, mint a kimeneté: 


istream£k operator::(Cistreamdg s, Seasonk x) 


( 


j 


const localek loc — s.getlocO; // az adatfolyam lokáljának kinyerése (§21.7.1) 


if (has facetcSeason io2(loc)) f // a szöveges ábrázolás beolvasása 
const Season iog f - use facetcSeason ior(loc); 
string buj; 
if ((szobufk£ ffrom str(buf,x))) s.setstate(ios base::failbit); 
return s; 

) 

int í; // a számábrázolás beolvasása 

S 22 í 

x — Season(i); 

return s; 


A hibakezelés egyszerű, a beépített típusok hibakezelésének stílusát követi. Azaz, ha a be- 
menő karakterlánc nem a választott lokál valamelyik Season-ját jelöli, az adatfolyam hibás 
(/ailure) állapotba kerül. Ha a kivételek megengedettek, ios base::failure kivétel kiváltásá- 
ra kerülhet sor (421.3.09. 


Vegyünk egy egyszerű tesztprogramot: 


intmainŐ  — // egyszerű teszt 


( 


úg, 


Season x; 


// az alapértelmezett lokál használata (nincs Season io facet); 
// egész értékű I/0-t eredményez: 

cin 55 Xx; 

cout cz x cz endi; 


locale loc(lIocaleO, new US season io); 
cout.imbue(loc);  // Season io facet-tel rendelkező lokál használata 
cin.imbue(loc); . // Season io facet-tel rendelkező lokál használata 


cin 55 Xx; 
cout cz x CZ endi; 


summer 
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bemenetre a program válasza: 


2. 
summer 


Ennek eléréséhez definiálnunk kell a US season io osztályt, amelyben megadjuk az évszak- 
ok karakterlánc-ábrázolását és felülírjuk a Season io azon függvényeit, amelyek a karakter- 
láncokat a felsorolt elemekre alakítják: 


class US season io : public Season io ( 
static const string seasons[/; 
public: 
const stringk to str(Season) const; 
bool from strCconst stringk, Seasonf ) const; 


// figyelem: nincs US season io::id 


Vé 
const string US season io::seasons[] - f "spring", "summer", "fall", "winter" ) ; 


const string US season io::to str(Season x) const 


( 
if (xsspring 11] winterzx) ( 
static const string ss - "Nincs ilyen évszak"; 
return ss; 


J 


return seasonslx]; 


J 


bool US season io::from str(const stringít s, Seasonk x) const 


( 
const string?" beg - kseasonslspringl; 
const string? end - kseasonslwinterj5 1; 
const string? p -— find(beg,end,5); // §3.8.1, §18.5.2 


if (p-send) return false; 
x - Season(p-beg); 
return true; 


Vegyük észre, hogy mivel a US season io csupán a Season io felület megvalósítása, nem 
adunk meg azonosítót a US season io számára. Sőt, ha a US season io-t Season io-ként 
akarjuk használni, nem is szabad ilyet tennünk. A lokálok műveletei (például a has facet, 
§D.3.1) arra támaszkodnak, hogy az azonos fogalmakat ábrázoló facet-eket ugyanaz az id 
azonosítja (4D.3). 
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A megvalósítással kapcsolatos egyetlen érdekes kérdés az, hogy mit kell tenni, ha érvény- 
telen Season kiírását kérik? Természetesen ennek nem lenne szabad megtörténnie. Az egy- 
szerű felhasználói típusoknál azonban nem ritka, hogy érvénytelen értéket találunk, így 
számításba kell vennünk ezt a lehetőséget is. Kiválthatnánk egy kivételt, de miután olyan 
egyszerű kimenettel foglalkozunk, amelyet emberek fognak olvasni, hasznos, ha a tartomá- 
nyon kívüli értékeket az , értéktartományon kívüli" szöveg is jelzi. A bemenetnél itt a kivé- 
telkezelés a 32 műveletre hárul, míg a kimenet esetében ezt a facet to strO függvénye vég- 
zi (hogy bemutathassuk a lehetőségekeD. Valódi programoknál a facet függvényei a be- és 
kimeneti hibák kezelésével egyaránt foglalkoznak, vagy csak jelentik a hibákat, a cc és 52 
műveletekre bízva azok kezelését. 


A Season io ezen változata arra támaszkodott, hogy a származtatott osztályok adják meg 
a lokálra jellemző karakterláncokat. Egy másik megoldás, hogy a Season io maga szerzi 
meg ezeket egy, a lokálhoz kapcsolódó adattárból (lásd §D.4.7). Gyakorlatként hagytuk an- 
nak kidolgozását, hogy egyetlen Season io osztályunk van, amelynek az évszakokat jelző 
karakterláncok a konstruktor paramétereként adódnak át (§D.6[2D. 


D.3.3. A lokálok és jellemzők használata 


A lokálok elsődlegesen a standard könyvtáron belül, az [/O adatfolyamokban használato- 
sak, de a /ocale a helyi sajátosságok ábrázolásának ennél általánosabb eszköze. A messages 
(S§D.4.7) például olyan facet, amelynek semmi köze a be- és kimeneti adatfolyamokhoz. 
Az iostream könyvtár esetleges bővítései, sőt, a nem adatfolyamokkal dolgozó be- és kime- 
neti eszközök is kihasználhatják a lokálok adta lehetőségeket, a felhasználó pedig a locale 
objektumok segítségével tetszőleges módon rendezheti a helyi sajátosságokat. 


A lokálokon és jellemzőkön alapuló eljárások általánossága révén a felhasználói facet-ek 
adta lehetőségek korlátlanok. A dátumok, időzónák, telefonszámok, társadalombiztosítási 
számok (személyi számok), gyártási számok, hőmérsékletek, általános (mértékegység, ér- 
ték) párok, irányítószámok, ruhaméretek, és ISBN számok mind megadhatók facet-ként. 
Mint minden , erős" szolgáltatással, a facet-ekkel is óvatosan kell bánni. Az, hogy valamit le- 
het jellemzőként ábrázolni, még nem jelenti azt, hogy ez a legjobb megoldás. A kulturális 
eltérések ábrázolásának kiválasztásakor a kulcskérdés — mint mindig — az, hogy milyen ne- 
héz a kód megírása, mennyire könnyű a kapott kódot olvasni, valamint hogy hogyan befo- 
lyásolják a döntések a kapott program fenntarthatóságát, illetve az [/D műveletek idő- és 
tárbeli hatékonyságát. 


D.4. Szabványos facet-ek 


D. Helyi sajátosságok 
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A standard könyvtár c/ocale: fejállománya a következő facet-eket nyújtja a classicO lokálhoz: 




















Szabványos facet-ek (a classic() lokálban) 
Kategória Rendeltetés Facet-ek 

§D.4.1 — collate Karakterláncok collatezCh: 

összehasonlítása 

$§D.4.2 numeric Számok be- és kivitele  numpunctizch: 
num gelizch: 
num putzch: 

SD.4.3 — monetary Pénz [/O moneypuncicch: 
moneypunci£Ch, true: 
money getizch: 
money putzch: 

$§D.4.4 time Idő [/O time getzch: 
time putzCch: 

SD.4.5  — ctype Karakterek osztályozása ctypezxCh: 
codecviZCh, char mbstate t2 

$D.4.7 — messages Üzenet-visszakeresés messageszch: 








A táblázatban a CA helyén char vagy wchar. t típus szerepelhet. Ha a felhasználónak arra 


van szüksége, hogy a szabványos [/O másfajta X karaktertípust kezeljen, a megfelelő facet- 
eket meg kell adnia az X számára. A codecutSX, char, mbstate t- (§D.4.6) például szükséges 
lehet az X és char típusok közötti átalakításokhoz. Az mbstate t típus arra való, hogy egy 
többájtos karakterábrázolás léptetési állapotait jelölje (§D.4.69; definiciója a ccwchar2 és 
a cCcwchar.h: fejállományokban található. Tetszőleges X karaktertípus esetében az 
mbstate t-nek a char. traitsZX2::state type felel meg. 
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A standard könyvtár további facet-jei a cocale: fejállományban a következők: 





Szabványos facet-ek 








Kategória — Rendeltetés Facet-ek 
§D.4.1 — collate Karakterláncok collate bynamezch: 
összehasonlítása 


§D.4.2 — numeric Számok be- és kivitele . numpunct bynamezcCh: 
num getcC In: 
num put£C, Out: 
§D.4.3 — monetary Pénz [/O moneypunct bynamecCh, International: 
money getiSC In: 
money putcC, Out: 
SD.4.4 time Idő [/OD time but bynamezCh: 
$D.4.5 — ctybe Karakterek osztályozása ctybe bynamezcCh: 


SD.4.7 — messages  Üzenet-visszakeresés — messages bynamezCh: 











A táblázatban szereplő jellemzők példányosításakor a CA charvagy wchar. tlehet; a Cbár- 
milyen karaktertípus (420.1), az International értéke true vagy false, ahol a true azt jelenti, 
hogy a valuta-szimbólum négykarakteres , nemzetközi" ábrázolását használjuk (§D.4.3.19. 
Az mbstate ttípus a többájtos karakter-ábrázolások léptetési állapotait jelöli (§D.4.6), meg- 
határozása a Ccwchar: és a cwchar.h: tejállományokban található. 


Az In és az Out bemeneti és kimeneti bejárók (iterátorok, §19.1, §19.2.1). Haa putés get 
jellemzőket ellátjuk ezekkel a sablonparaméterekkel, olyan facet-eket hozhatunk létre, 
amelyek nem szabványos átmeneti tárakhoz férnek hozzá (4D.4.2.2). Az iostream-ek átme- 
neti tárai (pufferei) adatfolyam átmeneti tárak, így bejáróik ostreambuf iterator-ok 
(419.2.6.1, §D.4.2.2), vagyis a hibakezeléshez rendelkezésünkre áll a failedO függvény. 


Az F byname az F facet-ből származik; ugyanazt a felületet nyújtja mint az F, de hozzáad 
egy konstruktort, amelynek egy lokált megnevező karakterlánc paramétere van (lásd 
$D.4.1-e0). Az F byname(mév) jelentése ugyanaz, mint az F localernév) szerkezeté. Az el- 
gondolás az, hogy a program végrehajtási környezetében egy nevesített lokálból (§D.2.1) 
kivesszük a szabványos /facet egy adott változatát: 
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void Kvectorsstring:£ v, const localed loc) 


( 


locale d1(loc, new collate bynamezcharr("da")); / dán karakterlánc-összehasonlítás 
// használata 

locale dk(d1, new ctybe bynamexcharr("da")); // dán karakterosztályozás használata 

sort(v.beginO, v.endO, dk); 

VES 


Az új dk lokál , dán stílusú" karakterláncokat fog használni, de megtartja a számokra vonat- 
kozó alapértelmezett szabályokat. Mivel a facet második paramétere alapértelmezés szerint 
0, a new művelettel létrehozott facet élettartamát a lokál fogja kezelni (4D.3). 


A karakterlánc paraméterekkel rendelkező /ocale-konstruktorokhoz hasonlóana  byname- 
konstruktorok is hozzáférnek a program végrehajtási környezetéhez. Ebből az következik, 
hogy nagyon lassúak azokhoz a konstruktorokhoz képest, amelyeknek nem kell a környe- 
zethez fordulniuk információért. Majdnem mindig gyorsabb, ha létrehozunk egy lokált és 
azután férünk hozzá annak jellemzőihez, mintha byname facet-eket használnánk több he- 
lyen a programban. Ezért jó ötlet, ha a facet-et egyszer olvassuk be a környezetből, majd 


később mindig a memóriában lévő másolatát használjuk: 


locale dkC("da");  // a dán lokál beolvasása (beleértve összes facet-jét) egyszer, 
// majd a dk lokál és jellemzőinek használata igény szerint 


void Kvectorsstring:£ v, const localek loc) 


( 
const collatezchar:£ col - use faceix collatezchar: r(dk); 
const collatezchar:£k ctyp - use facets ctypecchar: x(dR); 


locale d1(loc,coD; // dán karakterlánc-összehasonlítás használata 
locale d2(d1,ctyp); // dán karakterosztályozás és karakterlánc- 
// összehasonlítás használata 


sort(v.beginO, v.endO, d29; 
FÜLES 


A kategóriák egyszerűbbé teszik a lokálok szabványos /facet-jeinek kezelését. Például ha 
adott a dk lokál, létrehozhatunk belőle egy másikat, amely a dán nyelv szabályainak meg- 
felelően (ez az angolhoz képest három további magánhangzót jelenD) olvas be és hasonlít 
össze karakterláncokat, de megtartja a C---ban használatos számformátumot: 


locale dk us(locale::classicO, dk, collate IctypeJ; // dán betűk, amerikai számok 
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Az egyes szabványos facet-ek bemutatásánál további példákat nézünk meg a jellemzők 
használatára. A collate (§D.4.1) tárgyalásakor például a facet-ek sok közös szerkezetbeli tu- 
lajdonsága előkerül. 


Jegyezzük meg, hogy a szabványos facet-ek gyakran függnek egymástól. A num but pél- 
dául a numpunct-ra támaszkodik. Csak ha az egyes jellemzőket már részletesen ismerjük, 
akkor lehetünk képesek azokat sikeresen együtt használni, egyeztetni vagy új változataikat 
elkészíteni. Más szavakkal, a §21.7 pontban említett egyszerű műveleteken túl a lokálok 
nem arra valók, hogy a kezdők közvetlenül használják azokat. 


A jellemzők megtervezése gyakran nagyon körülményes. Ennek oka részben az, hogy a jel- 
lemzők nem rendszerezhető helyi sajátosságokat kell, hogy tükrözzenek, melyekre 
a könyvtár tervezője nincs befolyással; másrészt pedig az, hogy a C4- standard könyvtár- 
beli eszközeinek nagyrészt összeegyeztethetőnek kell maradniuk azzal, amit a C standard 
könyvtára és az egyes platformok szabványai nyújtanak. A POSIX például olyan eszközök- 
kel támogatja a lokálok használatát, melyeket a könyvtárak tervezői nem szabad, hogy fi- 
gyelmen kívül hagyjanak. 


Másfelől a lokálok és jellemzők által nyújtott szerkezet nagyon általános és rugalmas. 
A facet-ek bármilyen adatot tárolhatnak és azokon bármilyen műveletet végezhetnek. Ha 
az új facet viselkedését a szabályok nem korlátozzák túlságosan, szerkezete egyszerű és 
tiszta lehet (4D.3.29. 


D.4.1. Karakterláncok összehasonlítása 


A szabványos collate jellemző CA típusú karakterekből álló tömbök összehasonlítását teszi 
lehetővé: 


template Cclass Ch: 
class std::collate : public locale::facet ( 
bublic: 

typedef Ch char. type; 

typedef basic stringZCh: string type; 


explicit collate(size tr - 09; 


int compare(const Ch" b, const Ch" e, const Ch" b2, const Ch" e2) const 
€ return do compare(b,e,b2,e29; ) 


long hash(const Ch" b, const Ch" e) const f return do hash(b,e9; ) 
string type transform(const Ch"? b, const Ch" e) const f return do transform(b,e9; ) 
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static locale::id id; // facet-azonosító objektum (fD.2, $D.3, SD.3.1 
brotected: 
—collateO; // figyelem: védett destruktor 


virtual int do compare(const Ch"? b, const Ch" e, const Ch?" b2, const Ch? e2) const; 
virtual string type do transform(const Ch? b, const Ch" e) const; 
virtual long do hash(const Ch" b, const Ch" e) const; 


Hz 


A többi facet-hez hasonlóan a collate is nyilvános módon származik a facet osztályból és 
olyan konstruktorral rendelkezik, amelynek egyetlen paramétere azt mondja meg, hogy 


a locale osztály vezérli-e a jellemző élettartamát (§D.3). 


Jegyezzük meg, hogy a destruktor védett (protected). A collate nem közvetlen használatra 
való, inkább arra szánták, hogy minden (származtatott) összehasonlító osztály alapja legyen 
és a locale kezelje (S§D.3). A rendszerfejlesztőknek és a könyvtárak készítőinek a karakter- 
láncokat összehasonlító facet-eket úgy kell megírniuk, hogy a collate nyújtotta felületen ke- 
resztül lehessen használni azokat. 


Az alapvető karakterlánc-összehasonlítást a compareO függvény végzi, az adott collate-re 
vonatkozó szabályok szerint; 7-et ad vissza, ha az első karakterlánc több karakterből áll, 
mint a második, 0-át, ha a karakterláncok megegyeznek, és -7-et, ha a második karakter- 
lánc , nagyobb", mint az első: 


void Kconst stringé s1, const string£ 52, collatezchar:£ cmp) 

f 
const char? cs1 - s1.dataO; // mivel a compareO művelet charf[] tömbön dolgozik 
const char? cs2 — s2.dataO; 


switch ( cmp.compare(cs1,cs14s1.sizeO), cs2,cs24-s2.sizeO) ) 
f 
case O: // a cmp szerint azonos karakterláncok 
Jég 
break; 
case -1: //s1 c 52 
Mag 
break; 
case IT: //s1 2 52 
v/ZAbOTA 
break; 
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Vegyük észre, hogy a collate tagfüggvények CZ típusú elemekből álló tömböket hasonlíta- 
nak össze, nem basic string-eket vagy nulla végződésű C stílusú karakterláncokat, vagyis 
a O számértékű Ch közönséges karakternek minősül, nem végződésnek. A compareO ab- 
ban is különbözik a strcmpO-től, hogy pontosan a -17, 0, 7 értékeket adja vissza, nem egy- 


szerűen 0O-át és (tetszőleges) pozitív és negatív értékeket (420.4.1). 


A standard könyvtárbeli szring nem függ a lokáloktól, azaz a karakterláncok összehasonlí- 
tása az adott nyelvi változat karakterkészlete alapján történik (4C.2). Ezenkívül a szabvá- 
nyos string nem biztosít közvetlen módot arra, hogy meghatározzuk az összehasonlítási fel- 
tételt (20. fejezeb9. A lokáltól függő összehasonlításhoz a collate kategória compareO 
függvényét használhatjuk. Még kényelmesebb, ha a függvényt a lokál oberatorO operáto- 
rán keresztül, közvetett módon hívjuk meg (§D.2.49: 


void fconst string s1, const stringé s2, const char? n) 


( 


bool b -s1 --— s2; / összehasonlítás a megvalósítás karakterkészletének értékei szerint 


const char? cs1 - s1.dataO;  // mivel a compareO művelet charf[] tömbön dolgozik 
const char? cs2 - 52.dataO; 


typedef collatezchar: Col; 


const Colk glob - use facetzColx(localeO); // az érvényes globális lokálból 
int i0 - glob.compare(cs1,cs1551.sizeO), cs2, cs2-ts2.size0 ); 


const Colk my coll - use facetkColx(localeC");  // az előnyben részesített lokálból 
int il - my coll.compare(cs1,cs1--s1.sizeO), cs2, cs2--s2.sizeO 9; 


const Colg coll - use facetcColx(docalern)); . // az "n" nevű lokálból 
int i2 - coll.compare(cs1,cs1-s1.sizeO), cs2, cs24s2.sizeO ); 


int i3 - localeO(s1,529; . // összehasonlítás az érvényes globális lokál alapján 
int i4 - localeC")(s1,52); // összehasonlítás az előnyben részesített lokál alapján 
int i5 - localer(n)(s1,529; // összehasonlítás az "n" lokál alapján 


sg 





Itt 10--i3, i1--i4, és i2--i5, de könnyű olyan eseteket elképzelni, ahol i2, i3, és i4 értéke 
más. Vegyük a következő szavakból álló sorozatot egy német szótárból: 


Dialekt, Diat, dich, dichten, Dichtung 
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A nyelv szabályainak megfelelően a főnevek (és csak azok) nagy kezdőbetűsek, de a ren- 
dezés nem különbözteti meg a kis- és nagybetűket. 


Egy kis- és nagybetűket megkülönböztető német nyelvű rendezés minden D-vel kezdődő 
szót a d elé tenne: 


Dialekt, Diat, Dichtung, dich, dichten 


Az ű (umlautos a) , egyfajta a"-nak minősül, így a c elé kerül. A legtöbb karakterkészletben 
azonban az iű számértéke nagyobb a c számértékénél, következésképpen int( c) c int( a ), 
a számértékeken alapuló egyszerű alapértelmezett rendezés pedig a következőket adja: 


Dialekt, Dichtung, Diat, dich, dichten 


Érdekes feladat lehet egy olyan függvényt írni, amely a szótárnak megfelelően helyesen 
rendezi ezt a sorozatot (SD.6[3D. 


A hashO függvény egy hasítóértéket számít ki (417.6.2.3), ami magától értetődően 
hasítótáblák létrehozásakor lehet hasznos. 


A transformO függvény egy olyan karakterláncot állít elő, amelyet más karakterláncokkal 
összehasonlítva ugyanazt az eredményt kapjuk, mint amit a paraméter-karakterlánccal való 
összehasonlítás eredményezne. A transformO célja az, hogy optimális kódot készíthessünk 
az olyan programrészekből, ahol egy karakterláncot számos másikkal hasonlítunk össze. Ez 
akkor hasznos, ha karakterláncok halmazában egy vagy több karakterláncot szeretnénk 
megkeresni. 


A public compareO, a hash és a transformO függvények megvalósítását a do compareO, 
do hashO és do transformO nyilvános virtuális függvények meghívása biztosítja. Ezeket 
a ,do függvényeket" a származtatott osztályokban felül lehet írni. A kétfüggvényes megol- 
dás lehetővé teszi a könyvtár azon készítőjének, aki a nem virtuális függvényeket írja, hogy 
valamilyen közös szerepet biztosítson minden hívásnak, függetlenül attól, hogy mit csinál- 
nának a felhasználó által megadott do függvények. 


A virtuális függvények használata megőrzi a facet-ek többalakú (polimorfikus) természetét, 
de költséges lehet. A túl sok függvényhívás elkerüléséhez a locale pontosan meghatároz- 
hatja a használatos jellemzőket és bármennyi értéket a gyorsítótárba tehet, amennyire csak 
szüksége van a hatékony végrehajtáshoz (§4D.2.2). 
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A jellemzőket /ocale::id típusú statikus id tagok azonosítják (§D.3). A szabványos has facet 
és use facet függvények az azonosítók és jellemzők közötti összefüggéseken alapulnak 
(§D.3.19. Az azonos felületű és szerepű facet-eknek ugyanazzal az azonosítóval kell rendel- 
kezniük, így a collatezchar? és a collate bynamezchar? (§D.4.1.1) azonosítója is megegye- 
zik. Következésképpen két facet-nek biztosan különböző az azonosítója, ha (a locale szem- 
pontjából nézve) különböző függvényeket hajtanak végre, így ez a helyzet 
a numpunctiáchar? és a num putáchar? esetében is (§4D.4.2). 


D.4.1.1. Nevesített Collate 


A collate byname olyan jellemző, amely a collate azon változatát nyújtja az adott lokálnak, 
amelyet a konstruktor karakterlánc-paramétere nevez meg: 


template Cclass Ch: 
class std::collate byname : public collatezCh: f 
bublic: 

typedef basic stringZCh: string type; 


// létrehozás névvel rendelkező lokálból 
explicit collate byname(const char", size tr — 09; 


// figyelem: nincs azonosító és nincsenek új függvények 


brotected: 
-collate bynameO; // figyelem: védett destruktor 


// a collatezCh: virtuális függvényeinek felülírása 


int do compare(const Ch" b, const Ch"? e, const Ch" b2, const Ch" e2) const; 
string type do transform(const Ch" b, const Ch" e) const; 


long do hash(const Ch" b, const Ch" e) const; 
2 


Jo 
Így a collate byname arra használható, hogy kivegyünk egy collate-et egy, a program vég- 
rehajtási környezetében levő nevesített lokálból (§D.4). A végrehajtási környezetben 
a facet-eket egyszerűen fájlban, adatként is tárolhatjuk. Egy kevésbé rugalmas megoldás, ha 
a jellemzőket programszövegként és adatként ábrázoljuk egy , byname facet-ben. 


A collate bynamexchar? osztály olyan facet, amelynek nincs saját azonosítója (§D.3). A lo- 
kálokban a collate bynamezCh: és a collatezCh: felcserélhetők. Azonos lokál esetében 
a collate és a collate byname csak az utóbbi szerepében és a collate byname által felkínált 
további konstruktorban különbözik. 
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Jegyezzük meg, hogy a byname destruktor védett. Ebből következik, hogy lokális (helyi) 
változóként nem használhatunk . byname facet-et: 


void JO 


( 
collate bynamezchar: my coll("); /7 hiba: a my coll nem számolható fel 
1723 

J 


Ez azt a nézőpontot tükrözi, hogy a lokálok és jellemzők olyasmik, amiket a legjobb elég- 
gé magas szinten használni a programban, hogy a program minél nagyobb részére legyünk 
hatással. Erre példa a globális lokál beállítása (SD.2.3) vagy egy adatfolyam megtöltése 
(§21.6.3, §D.19. Ha szükséges, egy , byname osztályból egy nyilvános destruktorral rendel- 
kező osztályt származtathatunk és ebből az osztályból lokális változókat hozhatunk létre. 


D.4.2. Számok be- és kivitele 


A szám-kimenetet a num put facet kezeli, amely egy adatfolyam átmeneti tárba ír (421.6.4). 
A bemenet kezelése a num get dolga; ez is átmeneti tárból olvas. A num putés num get 
által használt formátumot a numpunct jellemző határozza meg. 


D.4.2.1. Számjegy-formátumok 


A beépített típusok (mint a bool, az int, és a double) be- és kimeneti formátumát 
a numpunct jellemző írja le: 


template class Ch: 
class std::numpunct : public locale::facet f 
bublic: 

typedef Ch char. type; 

typedef basic stringcCh? string type; 


explicit numpunctcsize tr - 09; 
Ch decimal pointO const; // "." a classicO lokálban 
Ch thousands sepO const; // ," a classicO lokálban 


string groupingO const; . //"" a classicO lokálban, jelentése: nincs csoportosítás 


string type truenameO const; // "true" a classicO lokálban 
string type falsenameO const; // "false" a classicO lokálban 
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static locale::id id; // facet-azonosító objektum (fD.2, $D.3, SD.3.1 
brotected: 
-numpunciO; 


// virtuális "do " függvények a nyilvános függvények számára (lásd §D.4.1) 
2 


Jo 
A grouping0 által visszaadott karakterlánc karaktereinek beolvasása kis egész értékek so- 
rozataként történik. Minden szám a számjegyek számát határozza meg egy csoport számá- 
ra. A 0. karakter a jobb szélső csoportot adja meg (ezek a legkisebb helyiértékű számje- 
gyek), az 1. az attól balra levő csoportot és így tovább. Így a 19044V9024003" egy számot 
ír le (pl. 123-45-6 789, feltéve, hogy a -" az elválasztásra használt karakter). Ha szükséges, 
a csoportosító minta utolsó karaktere ismételten használható, így a 9903" egyenértékű 
a 99093409034003"-mal. Ahogy az elválasztó karakter neve, a ihousands sepO mutatja is, 
a csoportosítást leggyakrabban arra használják, hogy a nagy egészeket olvashatóbbá te- 
gyék. A groupingO és thousands sepO függvények az egészek be- és kimeneti formátumát 
is megadják, a lebegőpontos számok szabványos be- és kimenetéhez azonban nem hasz- 
nálatosak, így nem tudjuk kiíratni az 1234567.89-et 1,234,567.89-ként csupán azáltal, 
hogy megadjuk a groupingO és thousands sepO függvényeket. 


A numpunct osztályból származtatással új formátumot adhatunk meg. A My punct jellem- 
zőben például leírhatjuk, hogy az egész értékek számjegyeit szóközökkel elválasztva és 
hármasával csoportosítva, a lebegőpontos értékeket pedig európai stílus szerint, tizedes- 
vesszővel elválasztva kell kiírni: 


class My punct : public std::numpunciáchar?: f 
bublic: 

typedef char char. type; 

typedef string string type; 


explicit My punctcsize t r - 0) : std::numpunciáchar(r) ( ) 
brotected: 
char do decimal pointO0 const f return " ; ) // vessző 
char do thousands sepO const f return " 5 ) / szóköz 
string do groupingO const f return "903"; ) // 3 számjegyű csoportok 


J; 


void JO 


( 
cout cz "Első stílus: " cz 12345678 cc "§$?t " cc 12345678 cz Mm 


locale loc(iIocaleO, new My puncUI; 
cout.imbue(]oc); 
cout cz "Második stílus: " 2 12345678 cc" ttt " cz 12345678 cz MS 


, 
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Ez a következő eredményt adja: 


Első stílus: 12345678 §"? 1.23457e106 
Második stílus: 12 345 678 "t" 1,23457e106 


Jegyezzük meg, hogy az imbueO az adatfolyamában másolatot tárol paraméteréről. Követ- 
kezésképpen az adatfolyam akkor is támaszkodhat egy megtöltött lokálra, ha annak erede- 
ti példánya már nem létezik. Ha a bemeneti adatfolyam számára be van állítva a boolalpha 
jelzőbit (421.2.2, §21.4.1), a true és false értékeket a truenameO és a falsenameŐ által 
visszaadott karakterláncok jelölhetik, más esetben a O és az 7. 


A numpunct byname változata (§D.4, §D.4.1) is adott: 


template Sclass Ch: 
class std::numpunct byname : public numpunctizCh: ff /§ ... "/); 


D.4.2.2. Számok kiírása 


Az átmeneti tárba való íráskor (§21.6.4) a kimeneti adatfolyamok (ostream) a num put jel- 
lemzőre támaszkodnak: 


template cclass Ch, class Out - ostreambujf iteratorzCh: 2 
class std::num put : public locale::facet f 
public: 

typedef Ch char. type; 

typedef Out iter. type; 


explicit num put(size tr - 09; 


Out put(Out b, ios baseg s, Ch fill, bool v) const; 

Out put(Out b, ios baseg s, Ch fill, long v) const; 

Out put(Out b, ios baseg s, Ch fill, unsigned long v) const; 
Out but(Out b, ios baseg s, Ch fill, double v) const; 

Out put(Out b, ios baseg s, Ch fill, long double v) const; 
Out put(Out b, ios baseg s, Ch fill, const void" v) const; 


static locale::id id; // facet-azonosító objektum (fD.2, $D.3, §D.3.1 
brotected: 
-num putO; 


// virtuális "do " függvények a nyilvános függvények számára (lásd §D.4.1) 
J; 
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Az Out kimeneti bejáró (iterátor) paraméter azonosítja, hogy a put a számértéket jelölő ka- 
raktereket hol helyezi el a kimeneti adatfolyam átmeneti tárában (§21.6.4). A putO értéke az 
a bejáró C(iterator), amely egy hellyel az utolsó karakter mögé mutat. 


Jegyezzük meg, hogy a num put alapértelmezett változata (amelynek bejárójával 
ostreambujf iteratorZCh: típusú karakterekhez lehet hozzáférni) a szabványos locale-ek 
(§D.4) része. Ha más változatot akarunk használni, akkor azt magunknak kell elkészítenünk: 


templatezclass Ch: 
class String numput : public std::-num put£Ch, tybpename basic stringzCh:::iterator: ( 
bublic: 

String numputoÓ : num putZCh, typename basic stringZCh:::iterator(1) ( ) 


j 


void f(nt i, stringét s, int bos) // "i" formázása "s"-be, a "pos" pozíciótól kezdve 


( 
String numputcchar?; f; 


ios basog xxx - coult; // a cout formázási szabályainak használata 
fput(s.beginO-xpos, xxx, " , U; // "i" formázása "s"-be 
? 


af 


Az ios base paraméterrel a formátumról és a lokálról kaphatunk információt. Például ha 
üres helyeket kell kitöltenünk, az ios base paraméter által megadott /i// karakter lesz fel- 
használva. Az átmeneti tár, amelybe b-n keresztül írunk, általában ahhoz az ostream-hez 
kapcsolódik, amelynek s a bázisosztálya. Az ios base objektumokat nem könnyű létrehoz- 
ni, mert a formátummal kapcsolatban több dolgot is szabályoznak és ezeknek egységesnek 
kell lenniük, hogy a kimenet elfogadható legyen. Következésképpen az ios base osztály- 
nak nincs nyilvános konstruktora (421.3.3). 


A putO függvények szintén ios base paramétereket használnak az adatfolyam lokáljának le- 
kérdezéséhez. A lokál határozza meg az elválasztó karaktereket (§D.4.2.1), a logikai értékek 
szöveges ábrázolását és a C/-ra való átalakítást. Például ha feltesszük, hogy a putO függ- 
vény ios base paramétere s, a pbutO függvényben ehhez hasonló kódot találhatunk: 


const localek loc — s.getlocO; 


VAK 

wchar. t w - use facetk ctypezchar: r(loc).widen(c); // átalakítás char-ról Ch-ra 
VUÁSTS 

string pnt - use facetZ numbunciáchar? (loc).decimal pointO; // alapértelmezés: 7." 
I. 


string flse - use facetz numpunciáchar? (loc) falsenameO; /7 alapértelmezés: "false" 
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A num putcchar:-hoz hasonló szabványos facet-eket a szabványos [/O adatfolyam-függ- 
vények általában automatikusan használják, így a legtöbb programozónak nem is kell tud- 
nia róluk. Érdemes azonban szemügyre venni, hogy a standard könyvtár függvényei ho- 
gyan használják a jellemzőket, mert jól mutatja, hogyan működnek a be- és kimeneti 
adatfolyamok, illetve a facet-ek. Mint mindig, a standard könyvtár most is érdekes progra- 
mozási eljárásokra mutat példákat. 


A num put felhasználásával az ostream készítője a következőket írhatja: 


templatexclass Ch, class Tr: 
ostreamé std::basic ostreamZCh, Tr:::operatorcc(double d) 


í 
sentry guardC this); // lásd §21.3.§ 
if (guard) return "this; 


ny 
if (use. facetz num putzCh: x(getlocO) putC"this, "this, this-2fillO, d) failedO) 
setstate(badbit); 


7 
catch (...)( 
handle ioexception("this); 


J 


return "this; 


Itt sok minden történik. Az , őrszem" (sentry) biztosítja, hogy minden művelet végrehajtó- 
dik (§21.3.8). Az ostream lokálját a getlocO) tagfüggvény meghívásával kapjuk meg, majd 
a lokálból a use facet sablon függvénnyel (§D.3.1) kiszedjük a num put jellemzőt. Miután 
ezt megtettük, meghívjuk a megfelelő putO függvényeket az igazi munka elvégzéséhez. 
A putO első két paraméterét könnyen megadhatjuk, hiszen az ostream-ből létrehozhatjuk 
az ostream buf bejárót (419.2.6), az adatfolyamot pedig automatikusan ios base bázisosz- 
tályára alakíthatjuk (421.2.1. 


A putO0 kimeneti bejáró paraméterét adja vissza. A bejárót egy basic ostream-ből szerzi 
meg, így annak típusa ostreambuf iterator. Következésképpen a failedO (§19.2.6.1) rendel- 


kezésünkre áll a hibaellenőrzéshez és lehetővé teszi számunkra, hogy megfelelően beállít- 
hassuk az adatfolyam állapotát. 


Nem használtuk a has facet függvényt, mert a szabványos facet-ek (§D.4) garantáltan ott 
vannak minden lokálban. Ha ez a garancia nem áll fenn, bad cast kivétel kiváltására kerül 
sor (4D.3.1. 
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A butO a do put virtuális függvényt hívja meg. Következésképpen lehet, hogy felhasználói 
kód hajtódik végre és az oberatorZ£O-nek fel kell készülnie arra, hogy a felülírt do putO 
által kiváltott kivételt kezelje. Továbbá lehet, hogy a num but nem létezik valamilyen ka- 
raktertípusra, így a use facetO az std::bad cast kivételt válthatja ki (§D.3.19. A beépített tí- 
pusokra, mint amilyen a double, a c£ viselkedését a Ct-4 szabvány írja le. Következéskép- 
pen nem az a kérdés, hogy a handle ioexceptionO függvénynek mit kell csinálnia, hanem 
az, hogyan csinálja azt, amit a szabvány előír. Ha a badbit jelzőbit az ostream kivétel álla- 
potára van állítva (421.3.69, a kivétel továbbdobására kerül sor, más esetben a kivétel keze- 
lése az adatfolyam állapotának beállítását és a végrehajtás folytatását jelenti. A badbit jelző- 
bitet mindkét esetben az adatfolyam állapotára kell állítani (§21.3.3): 


templatexclass Ch, class Tr: 
void handle ioexception(std::basic ostreamzCh Tr-g s) // a catch részből meghívva 


( 
if (s.exceptionsOdzios base::badbit) f 


try ( 
s.setstate(ios base::badbit); ) catchC...) f ? 
throw; // továbbdobás 


) 


s.setstate(ios base::badbiD); // basic ios::failure kivételt válthat ki 


J 


A try blokk azért szükséges, mert a setstate0 basic ios::failure kivételt válthat ki (421.3.3, 
§21.3.09. Ha azonban a badbit a kivétel állapotra állított, az operatorcc0-nek tovább kell 
dobnia azt a kivételt, amely a handle ioexceptionO) meghívását okozta (nem pedig egysze- 
rűen basic ios::failure kivételt kell kiváltania). 


A cct úgy kell megvalósítani a beépített típusokra, például a double-ra, hogy közvetlenül 
az adatfolyam átmeneti tárába írjunk. Ha a c-£-t felhasználói típusra írjuk meg, az ebből ere- 
dő nehézségeket úgy kerülhetjük el, hogy a felhasználói típusok kimenetét már meglévő tí- 
pusok kimenetével fejezzük ki (§D.3.29. 


D.4.2.3. Számok bevitele 


A bemeneti adatfolyamok (istream) a num getjellemzőre támaszkodnak az átmeneti tárból 
(§21.6.4) való olvasáshoz: 


template Sclass Ch, class In - istreambuf iteratorzCh: : 
class std::num get : public locale::facet f 
bublic: 

typedef Ch char. type; 

typedef In iter. type; 


explicit num get(size tr - 09; 
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// olvasás (b:e)-ből v-be, az s-beli formázási szabályok használatával; 


// hibajelzés az r beállításával: 
In getdn b, In e, ios based s, 
In getdn b, In e, ios based s, 
In getdn b, In e, ios based s, 
In getdn b, In e, ios basek s, 
In getdn b, In e, ios baseg s, 
In getdn b, In e, ios baseg s, 
In getdn b, In e, ios baseg s, 
In getdn b, In e, ios baseg s, 
In getdn b, In e, ios baseg s, 


static locale::id id; 
brotected: 
-num gelO; 


ios base:: 
ios base:: 
ios base:: 
ios base:: 
ios base:: 
ios base:: 
ios base:: 
ios base:: 
ios base:: 


iostateg r, boolk v) const; 

iostateg r, long v) const; 

iostateg r, unsigned shortk v) const; 
iostatek r, unsigned intik v) const; 
iostatekg r, unsigned long£ v) const; 
iostateg r, floatkg v) const; 

iostatek r, doubleg v) const; 
iostateg r, long doublekg v) const; 
iostategt r, void? v) const; 


// facet-azonosító objektum (fD.2, §D.3, $D.3.1 


// virtuális "do " függvények a nyilvános függvények számára (lásd §D.4.1) 


3 


A num get szerkezete alapvetően a num put-éhoz (§D.4.2.2) hasonló. Mivel inkább olvas, 
mint ír, a get0-nek egy bejárópárra van szüksége, az olvasás célpontját meghatározó para- 
méter pedig egy referencia. AZ iostate típusú r változó úgy van beállítva, hogy tükrözze az 
adatfolyam állapotát. Ha a kívánt típusú értéket nem lehet beolvasni, az r-ben a failbit be- 
állítására kerül sor, ha elértük a bemenet végét, az eofbit-ére. A bemeneti műveletek az 7-t 
arra használják, hogy eldöntsék, hogyan állítsák be az adatfolyam állapotát. Ha nem történt 
hiba, a beolvasott érték a v-n keresztül értékül adódik; egyébként a v változatlan marad. 


Az istream készítője a következőket írhatja: 


templatexclass Ch, class Tr: 


istreamé std::basic istreamzCh, Tr::oberator:x(doublek d) 


( 
sentry guardC this); // lásd §21.3.§ 
if (guard) return "this; 
iostate state — O; // jó 


istreambuj" iteratorzCh: eos; 
double dd; 


try ( 


use faceiz num getzCh: x(getlocO).get( "this, eos, "this, state,dd4); 


J 
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catch (...) ( 
handle ioexceptionCtthis); // lásd §D.4.2.2 
return "this; 


) 

if (state--0 I 1 state-—eofbiD) d - dd; // d értékének beállítása csak akkor, 
// ha a get sikerrel járt 

setstate(state); 

return "this; 


Az istream számára megengedett kivételeket hiba esetén a setstate0 függvény váltja ki 


(421.3.09. 


Egy numpunct jellemzőt — mint amilyen a my numpunct a §D.4.2 pontban — megadva nem 
szabványos elválasztó karaktereket használva is olvashatunk: 


void JO 
( 


cout cz "Első stílus: " 

int i1; 

double d1; 

cin 5511 55 d1; // beolvasás a szabványos "12345678" forma használatával 


locale loc(locale::classicO, new My puncD; 

cin.imbue(loc); 

cout cz "Második stílus: " 

int i2; 

double d2; 

cin25il 22 d2;, // beolvasás a "12 345 678" forma használatával 


Ha igazán ritkán használt számformátumokat szeretnénk beolvasni, felül kell írnunk 
a do gető függvényt. Megadhatunk például egy num get facet-et, amely római számokat 
olvas be ( XXI vagy MM, SD.6[15D. 


D.4.3. Pénzértékek be- és kivitele 


9) 


A pénzösszegek formázásának módja az ,egyszerű" számok formázásához hasonlít 
(§D.4.2), az előbbinél azonban a kulturális eltérések jelentősége nagyobb. A negatív össze- 
geket (veszteség, tartozás, mondjuk -1,25) például egyes helyeken pozitív számokként, zá- 
rójelben kell feltüntetni (1,259. Az is előfordulhat, hogy a negatív összegek felismerésének 


megkönnyítésére színeket kell használnunk. 
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Nincs szabványos , pénz típus". Ehelyett kifejezetten a ,pénz" facet-eket kell használnunk 
az olyan számértékeknél, amelyekről tudjuk, hogy pénzösszegeket jelentenek: 


class Money f // egyszerű típus pénzösszegek tárolására 
long int amount; 
bublic: 


Moneydlong int i) : amount() ( ) 

operator long intO const f return amount; ) 
j; 
ZEN 


void f(dong int i) 
( 


J 


cout ££ "Érték- " cz i c " Összeg- " cz Money(i) cz endi; 


Ezen facet-ek feladata az, hogy jelentősen megkönnyítsék az olyan kimeneti műveletek 
megírását a Money típusra, melyek az összeget a helyi szokásoknak megfelelően írják ki 
Cdásd §D.4.3.2-D. A kimenet a cout lokáljától függően változik: 


Érték- 1234567 Összeg- $12345.67 
Érték- 1234567 Összeg- 12345,67 DKK 
Érték- -1234567 Összeg- $-12345.67 
Érték- -1234567 Összeg- -$12345.67 
Érték- -1234567 Összeg- (CHF12345,67) 


A pénzértékek esetében rendszerint alapvető a legkisebb pénzegységre is kiterjedő pontos- 
ság. Következésképpen én azt a szokást követem, hogy inkább a , fillérek" (penny, ore, cent 
stb.) számát ábrázolom egész értékekkel, nem a , forintokét" (font, korona, dínár, euró stb.). 
Ezt a megoldást a money punct frac digitsO függvénye támogatja (§D.4.3.1). A , tizedes-el- 
választót" a decimal pointO adja meg. 


A money base jellemző által leírt formátumon alapuló bemenetet és kimenetet kezelő függ- 
vényeket a money getés money put facet-ek biztosítják. 


A be- és kimeneti formátum szabályozására és a pénzértékek tárolására egy egyszerű 
Money típust használhatunk. Az első esetben a pénzösszegek tárolására használt (más) tí- 
pusokat kiírás előtt a Money típusra alakítjuk, a beolvasást pedig szintén Money típusú vál- 
tozókba végezzük, mielőtt az értékeket más típusra alakítanánk. Kevesebb hibával jár, ha 
a pénzösszegeket következetesen a Money típusban tároljuk: így nem feledkezhetünk meg 
arról, hogy egy értéket Money típusra alakítsunk, mielőtt kiírnánk és nem kapunk bemene- 
ti hibákat, ha a lokáltól függetlenül próbálunk pénzösszegeket beolvasni. Lehetséges azon- 
ban, hogy a Money típus bevezetése kivitelezhetetlen, ha a rendszer nincs felkészítve rá. 
Ilyen esetekben szükséges a Money-konverziókat alkalmazni az olvasó és író műveleteknél. 
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D.4.3.1. A pénzértékek formátuma 


A pénzösszegek megjelenítését szabályozó moneypunct természetesen a közönséges szá- 
mok formátumát megadó numpunct facet-re (§D.4.2.1) hasonlít: 


class std::money base f 


bublic: 
enum part ( none, space, symbol, sign, value ) ; // az elrendezés részei 
struct pattern ( char field[ál; ); // elrendezés 


5 
template Sclass Ch, bool International - falsez 
class std::moneypunct : public locale::facet, public money base f 
bublic: 

typedef Ch char. type; 

typedef basic stringZCh: string type; 


explicit moneypunct(size tr — 09; 


Ch decimal pointő const; // 7. a classicO lokálban 
Ch thousands sepO const; // , a classicO lokálban 
string groupingO const; . //"" a classicO lokálban, jelentése: nincs csoportosítás 


string type curr. symbolO const; //"$" a classicO lokálban 
string type positive signO const; 7" a classicO lokálban 
string type negative signO const; — //"-" a classicO lokálban 


int frac digitsO const; // számjegyek száma a tizedesvessző után; 2 a classicO lokálban 
battern pos formatO const; — //€ symbol, sign, none, value ? a classicO lokálban 
battern neg formatO const; — //€ symbol, sign, none, value ? a classicO lokálban 


static const bool intl - International; . // a "nemzetközi" pénzformátum használata 


static locale::id id; // facet-azonosító objektum (fD.2, §D.3, §D.3.1 
brotected: 
-moneypunctO; 


// virtuális "do " függvények a nyilvános függvények számára (lásd §D.4.1) 


J; 


A moneypunct szolgáltatásait elsősorban a money putés money get jellemzők készítőinek 
szánták (§D.4.3.2, §D.4.3.3). 


A decimal pointO, thousands sepO, és groupingO tagok úgy viselkednek, mint a velük 
egyenértékű függvények a numpunct facet-ben. 
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A curr. symbolO, positive sign és negative signO tagok rendre a valutajelet ($, X FrF, 
DKP,), a pluszjelet és a mínuszjelet jelölő karakterláncot adják vissza. Ha az International 
sablonparaméter értéke true volt, az intl tag szintén true lesz és a valutajelek , nemzetközi" 
ábrázolása lesz használatos. A nemzetközi ábrázolás egy négy karakterből álló karakterlánc: 


"USD " 
"DKK " 
"EUR " 


Az utolsó karakter általában szóköz. A három betűs valuta-azonosítót az ISO-4217 szabvány 
írja le. Ha az International értéke false, , helyi" valutajelet — $, £ vagy £— lehet használni. 


A pos formatÓ és neg formatÓ által visszaadott minta (pattern) négy részből (parD) áll, 
amelyek a számérték, a valutajel, az előjel és az üreshely megjelenítésének sorrendjét adják 
meg. A leggyakoribb formátumok ezt a mintát követik: 


t$ 12345 — /(v sign, symbol, space, value ), ahol a positive signO visszatérési értéke "4" 
$4123.45 //€ symbol, sign, value, none ), ahol a positive signO visszatérési értéke "4-" 
$123.45 // €£ symbol, sign, value, none ), ahol a positive signO visszatérési értéke "" 
$123.45- // € symbol, value, sign, none ) 

-123.45 DKK / ( sign, value, space, symbol ) 

($123.45) // ( sign, symbol, value, none ), ahol a negative signO visszatérési értéke "0" 
(123.45DKK) //f sign, value, symbol, none ), ahol a negative signO visszatérési értéke "0" 


A negatív számok zárójeles ábrázolását a negative signO függvény visszatérési értékeként 
a 0 karakterekből álló karakterláncot definiálva biztosítjuk. Az előjel-karakterlánc első ka- 
raktere oda kerül, ahol a sign (előjel található a mintában, a maradék pedig a minta többi 
része után következik. Ezt a megoldást leggyakrabban ahhoz a szokásos pénzügyi jelölés- 
hez használják, miszerint a negatív összegeket zárójelben tüntetik fel, de másra is fel lehet 
használni: 


-$123.45 // € sign, symbol, value, none ), ahol a negative signO visszatérési értéke "-" 
t$123.45silly /1 sign, symbol, value, none ), ahol a negative sign 
// visszatérési értéke "? silly" 


Az előjel, érték és szimbólum (sign, value, symbol értékek csak egyszer szerepelhetnek 
a mintában. A maradék érték space (üreshely) vagy none (semmi) lehet. Ahol space szere- 
pel, oda legalább egy üreshely karakternek kell kerülnie, a none nulla vagy több üreshely 
karaktert jelent (kivéve ha a none a minta végén szerepe]. 
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Ezek a szigorú szabályok néhány látszólag ésszerű mintát is megtiltanak: 


battern pat - f sign, value, none, none ); // hiba: a symbol nincs megadva 


A decimal pointő helyét a frac digitsO függvény jelöli ki. A pénzösszegeket általában 
a legkisebb valutaegységgel ábrázolják (§4D.4.3), ami jellemzően a fő egység századrésze 
(például cent és dollár), így a frac digitsO értéke általában 2. 


Következzen egy egyszerű formátum, facet-ként megadva: 


class My money io : public moneypunciKchar true: f 
bublic: 
explicit My money io(size t r - 0) : moneypuncicchar truex(r) f ) 


char. type do decimal point0 const f return "5 ) 
char. type do thousands sepO const f return § ; ? 
string do groupingO const f return "4903409034003"; ) 





string type do curr. symbolO const f return "USD "; ) 
string type do positive signO const ( return "; ? 
string type do negative signO const f return "OV; ) 





int do frac digitsO const ( return 2; ) // 2 számjegy a tizedesvessző után 


battern do pos formatO const 


S 
t 


static pattern pat - f sign, symbol, value, none ) ; 


return pat; 

, 

battern do neg format0 const 

( 
static pattern pat -— f sign, symbol, value, none ? ; 
return pat; 

, 


J; 


Ezt a facet-et használjuk a Money alábbi be- és kimeneti műveleteiben is (4D.4.3.2 és 


SD.4.3.3). 
A moneypunct byname változata (§D.4, §D.4.1) is adott: 


template Sclass Ch, bool Intl - false 
class std::moneypunct byname : bublic moneypunciZCh, Intl2 (/? ... "72; 
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D.4.3.2. Pénzértékek kiírása 


A money put a moneypunct által meghatározott formátumban írja ki a pénzösszegeket. 
Pontosabban, a money put olyan butO függvényeket nyújt, amelyek megfelelően formá- 
zott karakter-ábrázolásokat tesznek egy adatfolyam átmeneti tárába: 


template cclass Ch, class Out - ostreambujf iteratorzCh: 2 
class std::money put : public locale::facet ( 
bublic: 

typedef Ch char. type; 

typedef Out iter. type; 

typedef basic stringZCh? string type; 


explicit money put(size tr — 09; 


Out pu(Out b, bool intl, ios baseg s, Ch fill, long double v) const; 
Out pur(Out b, bool intl, ios basek s, Ch fill, const string typek v) const; 


static locale::id id; // facet-azonosító objektum (fD.2, $D.3, §D.3.1) 
brotected: 
-money putO; 


// virtuális "do " függvények a nyilvános függvények számára (lásd §D.4.1) 


94 


A b, s, fillés v paraméterek ugyanarra használatosak, mint a num but jellemző putO függ- 
vényeiben (§D.4.3.2.29. Az intl paraméter jelzi, hogy a szabványos négykarakteres , nemzet- 
közi" valutaszimbólum vagy , helyi" valutajel használatos-e (§D.4.3.19. 


Ha adott a money putjellemző, a Money osztály számára($D.4.3) kimeneti műveletet írhatunk: 


ostreamk operatorsgostreamk s, Money m) 


( 
ostream::sentry guard(5); // lásd §21.3.8 
if (guard) return s; 


try ( 
const money putcchar:k f- use facetk money putáchar: (s .getlocO); 
if (m--static castglong doublex(m)) f // m long double-ként ábrázolható 


if (put(s,true,s,s fill0,m) failedO) s.setstate(ios base::badbit); 


else ( 
ostringstream u; 
v cz m; // karakterlánc-ábrázolásra alakít 
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if fputcs,true,s,s illo, v.strO) failedO) s.setstate(ios base::badbiD; 
f 
) 
catch (...) ( 
handle ioexception(s); — // lásd §D.4.2.2 
fi 


return S; 


J 


Ha a long double nem elég pontos a pénzérték ábrázolásához, az értéket karakterlánccá 
alakítjuk és azt írjuk ki az ilyen paramétert váró putO függvénnyel. 


D.4.3.3. Pénzértékek beolvasása 


A money get a moneypbunct által meghatározott formátumnak megfelelően olvassa be 
a pénzösszegeket. Pontosabban, a money get olyan get0 függvényeket nyújt, amelyek 
a megfelelően formázott karakteres ábrázolást olvassák be egy adatfolyam átmeneti tárából: 


template Sclass Ch, class In — istreambuf iteratorZCh: 5 
class std::money get : public locale::facet f 
bublic: 

typedef Ch char. type; 

typedef In iter. type; 

typedef basic stringZCh? string type; 


explicit money get(size tr — 09; 


// olvasás (b:e)-ből v-be, az s-beli formázási szabályok használatával; 

// hibajelzés az r beállításával: 

In getdn b, In e, bool intl, ios basekg s, ios base::iostatek r, long doublek v) const; 
In getdn b, In e, bool intl, ios basek s, ios base::iostateg r, string tybek v) const; 


static locale::id id; // facet-azonosító objektum (fD.2, $D.3, SD.3.1 
brotected: 
-money getO; 


// virtuális "do " függvények a nyilvános függvények számára (lásd §D.4.1) 
2 


Jo 
A b, s, fill, és v paraméterek ugyanarra használatosak, mint a num get jellemző getO függ- 
vényeiben (§D.4.3.2.29. Az intl paraméter jelzi, hogy a szabványos négykarakteres , nemzet- 
közi" valutaszimbólum vagy , helyi" valutajel használatos-e (§D.4.3.1. 
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Megfelelő money get és money put jellemzőpárral olyan formában adhatunk kimenetet, 
amelyet hiba és adatvesztés nélkül lehet visszaolvasni: 


int mainŐ 


Money m; 
while (cin:2m) cout ££ m cz Ni; 


J 


Ez az egyszerű program kimenetét el kell, hogy fogadja bemenetként is. Sőt, ha a progra- 
mot másodszor is lefuttatjuk az első futtatás eredményével, a kimenetnek meg kell egyez- 
nie a program eredeti bemenetével. 


A Money osztály számára a következő megfelelő bemeneti művelet lehet: 


istiream£k operator::(istreamg s, Moneyk m) 


( 
istream::sentry guard(59; // lásd §21.3.8 
if (guard) try ( 
ios base::iostate state- 0;  // jó 
istreambuf iteratorcchar: eos; 
string str; 
use facetiz money getéchar: 2(s.getlocO).get(s, eos, true, state, Str); 
if (state--0 11 state-—ios base::eofbiDf  // csak akkor állít be értéket, 
// ha a getőŐ sikerrel járt 
long int i — strtol(str.c. strO,O,0); 
if (errno--ERANGE) 
state 1- ios base::failbit; 
else 
m - i; // csak akkor állítja be m értékét, ha az átalakítás long int-re sikerült 
s.setstate(state); 
j 
j 
catch (...)( 
handle ioexception(s); — // lásd §D.4.2.2 
j 
return S; 


J 
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D.4.4. Dátum és idő beolvasása és kiírása 


Sajnos a C4- standard könyvtára nem nyújt megfelelő dátum típust, de a C standard könyv- 
tárából alacsonyszintű eszközöket örökölt a dátumok és időtartományok kezeléséhez. Ezek 
a C-beli eszközök szolgálnak a C-- rendszerfüggetlen időkezelő eszközeinek alapjául. 


A következőkben azt mutatjuk be, hogyan igazítható a dátum és idő megjelenítése a lokál- 
hoz, továbbá példákat adunk arra, hogyan illeszthető be egy felhasználói típus (Date) az 
iostream (21. fejeze) és locale (§D.2) által nyújtott szerkezetbe. A Date típuson keresztül 
olyan eljárásokkal is megismerkedünk, amelyek segíthetik az időkezelést, ha nem áll ren- 
delkezésünkre a Date típus. 


D.4.4.1. Órák és időzítők 


A legtöbb rendszer a legalacsonyabb szinten rendelkezik egy finom időzítővel. A standard 
könyvtár a clockO függvényt bocsátja rendelkezésünkre, amely megvalósítás-függő clock t 
típusú értékkel tér vissza. A clockO eredménye a CTOCK PER SEC makró segítségével sza- 
bályozható. Ha nincs hozzáférésünk megbízható időmérő eszközhöz, akkor így mérhetjük 
meg egy ciklus idejét: 


int main(int argc, char" argul)) // 56.1.7 
( 
int n - atoi(argul1)); // 5§20.4.1 
clock t t1 — clockO; 
if (1 —- clock t(-1)) ( // clock t(-1) jelentése: "a clockO nem működik" 
cerr S£ "Sajnos nincs óránk Mn"; 
exit( 1); 
) 


for (int í - O; i £ n; it) do somethingO; // időzítő ciklus 


clock t t2 -— clockO; 
if G2 -—- clock t(-1) f 
cerr c£ "Túlcsordulás Mm; 
exit(29; 
) 
cout c£ "A do somethingO " cz n cz " alkalommal való végrehajtása " 
aZ double(t12-t1/CLOCKS PER SEC cz " másodpercet vett igénybe" 
za " (mérési érzékenység: " cz CTOCKS PER SEC cz " per másodperc) MU"; 
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Az osztás előtt végrehajtott double(t2-t1) átalakítás azért szükséges, mert a c/ock t lehet, 
hogy egész típusú. Az, hogy a clockO mikor kezd futni, az adott nyelvi változattól függ; 
a függvény az egyes programrészek futási idejének mérésére való. A clockO által vissza- 
adott t] és t2értékeket alapul véve a double(t2-t1//CLOCK PER SECa rendszer legjobb kö- 
zelítése két hívás közt eltelt időre (másodpercben). 


Ha az adott feldolgozóegységre nincs megadva a clockO függvény vagy ha az idő túl hosszú 
ahhoz, hogy mérhető legyen, a clockO a clock t(-1) értéket adja vissza. 

A clockO függvény a másodperc töredékétől legfeljebb néhány másodpercig terjedő időtar- 
tományok mérésére való. Például ha a clock t egy 32 bites előjeles egész és 
a CLOCK PER SECértéke 1 000 000, a clockO függvénnyel az időt 0-tól valamivel több mint 
2000 másodpercig (körülbelül fél óráig) mérhetjük (a másodperc milliomod részében). 


A programokról lényegi méréseket készíteni nem könnyű. A gépen futó többi program je- 
lentősen befolyásolhatja az adott program futási idejét, nehéz megjósolni a gyorsítótárazás 
és az utasításcsövek hatásait és az algoritmusok nagymértékben függhetnek az adatoktól is. 
Ha meg akarjuk mérni egy program futási idejét, futtassuk többször és vegyük hibásnak 
azokat az eredményeket, amelyek jelentősen eltérnek a többitől. 


A hosszabb időtartományok és a naptári idő kezelésére a standard könyvtár a time ttípust 
nyújtja, amely egy időpontot ábrázol; valamint a tm szerkezetet, amely az időpontokat , ré- 
szeikre" bontja: 


typedefmegvalósítás függő time t; — // megvalósítás-függő aritmetikai típus (§4.1.1) 
// képes időtartomány ábrázolására, 
// általában 32 bites egész 


struct tm (f 
inttm sec; // a perc másodpercei (O,61/; a 60 és a 61 "szökő-másodpercek" 
inttm min; // az óra percei [0,59/ 


inttm hour: // a nap órái [0,23] 

inttm mday; — // a hónap napjai (1,31/ 

inttm mon; // az év hónapjai (0,11]; a O jelentése "január" (figyelem: NEM [1:120 
inttm year; // évek 1900 óta; a O jelentése "1900", a 102-é "2002" 


inttm wday; —— // napok vasárnap óta [/O,6/; a O jelentése "vasárnap" 
inttm yday; // napok január 1 óta (0,365/; a 0 jelentése "január 1." 
int tm isdst; // nyári időszámítás jelző 


VA 


A szabvány csak azt biztosítja, hogy a im rendelkezik a fenti említett int típusú tagokkal, azt 
nem, hogy a tagok ilyen sorrendben szerepelnek vagy hogy nincsenek más tagok. 
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A time t és tm típusok, valamint a hozzájuk kapcsolódó szolgáltatások a Cctime: és 
Ztime.h: fejállományokban találhatók: 


clock t clockO; // órajelek száma a program indulása óta 


time t time(time E" pi); // érvényes naptári idő 
double difftime(time t t2, time tt1;  // t2-t1 másodpercben 


tm" localtimerconst time tt pp; // "pt értéke helyi idő szerint 
tm?" gmtime(const time tf" pD; // "pt értéke greenwichi középidő (GMT) szerint, vagy 0 
// (hivatalos neve: Coordinated Universal Time, UTC) 


time t mktime(tm"? ptm); // "ptm értéke time t formában, vagy time t(-1) 


char? asctime(const tm" ptm); // "ptm egy C stílusú karakterlánccal ábrázolva 
// pl. "Sun Sep 16 01:03:52 1973" 


char? ctime(const time t" t) f return asctime(docaltime(1); ) 


Vigyázzunk: mind a localtimeO, mind a gmtimeO statikusan lefoglalt objektumra mutató 
"tm típusú értéket ad vissza, vagyis mindkét függvény következő meghívása meg fogja vál- 
toztatni az objektum értékét. Ezért rögtön használjuk fel a visszatérési értéket vagy másol- 
juk a tm-et olyan memóriahelyre, amit mi felügyelünk. Ugyanígy az asctimeO függvény is 
statikusan lefoglalt karaktertömbre hivatkozó mutatót ad vissza. 


A tm típus legalább tízezer évnyi dátumot (ez a legkisebb egész esetében körülbelül 
a [-32000,32000] tartomány) képes ábrázolni. A time t azonban általában 32 bites (előjeles) 
long int. Ha másodperceket számolunk, a time t nem sokkal több, mint 68 évet tud ábrá- 
zolni valamilyen , 0. évtől" mindkét , irányban". Az ,alapév" rendszerint 1970, a hozzá tarto- 
zó alapidő pedig január 1., 0:00 GMT (UTC. Ha a time t32 bites előjeles egész, akkor 2038- 
ban futunk ki az , időből", hacsak nem terjesztjük ki a time t-t egy nagyobb egész típusra, 
ahogy azt már néhány rendszeren megg is tették. 


A time t alapvetően arra való, hogy a , jelenhez közeli időt" ábrázoljuk, ezért nem szabad 
elvárnunk, hogy képes legyen az [1902,2038] tartományon kívüli dátumokat is jelölni. Ami 
még ennél is rosszabb, nem minden időkezelő függvény kezeli azonos módon a negatív 
számokat. A , hordozhatóság" miatt az olyan értékeknek, amelyeket tm-ként és time t-ként 
is ábrázolni kell, az [1920,2038] tartományba kell esniük. Azoknak, akik az 1970-től 2038-ig 
terjedő időkereten kívüli dátumokat szeretnének ábrázolni, további eljárásokat kell kidol- 
gozniuk ahhoz, hogy ezt megtehessék. 
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Ennek egyik következménye, hogy az mktimeO hibát eredményezhet. Ha az mktimeO pa- 
raméterét nem lehet time t-ként ábrázolni, a függvény a time t(-1) hibajelzést adja vissza. 


Ha van egy sokáig futó programunk, így mérhetjük le futási idejét: 


int main(int argc, char" argul) , / §6.1.7 
( 


time t t1 — time(09; 

do a lot(argc, argu); 

time t t2 — time(09; 

double d — difftime(t2 t 1; 

cout ££ "A do a lotO végrehajtása" cz d c£ " másodpercig tartott Nn"; 


Ha a timeO paramétere nem 0, a függvény eredményeként kapott idő értékül adódik 
a függvény time ttípusra mutató paraméterének is. Ha a naptári idő nem elérhető (mond- 
juk valamilyen egyedi processzoron), akkor a time t(-1) érték adódik vissza. A mai dátu- 
mot a következőképpen próbálhatjuk meg óvatosan megállapítani: 


int mainŐ 


( 


time tt; 


if (time(kt) -- time t(-1)) f / a time t(-1) jelentése: "a timeO0) nem működik" 
cerr ££ "Az idő nem állapítható meg Mn"; 
exit( 1; 

j 


tm? gt - gmtime(k 1); 
cout ££ gt-otm mont1 cz [// c£ gt-xtm mday cz [/ 22 19004gt-2tm year cz endi; 


D.4.4.2. Egy dátum osztály 


Amint a §10.3 pontban említettük, nem valószínű, hogy egyetlen Date típus minden igényt 
ki tud szolgálni. A dátum felhasználása többféle megvalósítást igényel és a XIX. század előtt 
a naptárak nagyban függtek a történelem szeszélyeitől. Példaként azonban a §10.3-hoz ha- 
sonlóan készíthetünk egy Date típust, a time ttípust felhasználva: 


class Date ( 
bublic: 
enum Month f jan-1, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec ? ; 
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class Bad date (7; 


Date(int dd, Month mm, int yy); 
DateO; 


Jriend ostreamk operatorss(ostreamá s, const Datek d); 
eszi 

brivate: 
time t d; // szabványos dátum- és időábrázolás 

2. 

J; 


Date:: Date(int dd, Month mm, int yy) 
( 
immx-f07; 
if (ddco 11 31cda) throw Bad dateoO; // tűlegyszerűsített: lásd §10.3.1 
x.tm mday - dd; 
if (mnmxjan 11 decsmm) throw Bad dateO; 
x.tm mon - mm-1I; //atm mon O alapú 
x.tm year - yy-1900; /atm year 1900 alapú 
d - mktime(£ x); 


j 


Date::DateO 

( 
d - time(0)9; // alapértelmezett Date: a mai nap 
if (d — time t(-1)) throw Bad dateO; 


j 


A feladat az, hogy a c£ és 55 operátorokat a Date típusra lokálfüggő módon valósítsuk 


meg. 


D.4.4.3. Dátum és idő kiírása 


A num put facet-hez (§D.4.2) hasonlóan a time butis putO függvényeket ad, hogy bejáró- 
kon keresztül az átmeneti tárakba írhassunk: 


template cclass Ch, class Out - ostreambuf iteratorzCh: - 
class std::time put : public locale::facet f 
bublic: 

typedef Ch char. type; 

typedef Out iter. type; 


explicit time put(size tr — 09; 
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// írás az s adatfolyam átmeneti tárába b-n keresztül, az fmt formátum használatával 
Out put(Out b, ios baseg s, Ch fill, const tm" t, 


const Ch?" fjmt b, const Ch?" fmt e) const; 


Out pu(Out b, ios baseg s, Ch fill, const tm" t, char fmt, char mod - 0) const 
f return do put(b,s fill,t. fmt, mod); ) 


static locale::id id; // facet-azonosító objektum (fD.2, $D.3, §D.3.1) 


brotected: 


-time putO; 


virtual Out do put(Out, ios basek, Ch, const tm", char, char) const; 


); 


A put(b,s filltfjmt b. fmt e) a t-ben lévő dátumot b5-n keresztül az s adatfolyam átmeneti tá- 
rába helyezi. A /ill karakterek a kitöltéshez használatosak, ha az szükséges. A kimeneti for- 
mátumot a printfO formázóhoz hasonló (mt b fmt e) formázási karakterlánc (vagy formá- 
tumvezérlő) határozza meg. A tényleges kimenethez a printfO-hez hasonló (421.8) 
formátum használatos, ami a következő különleges formátumvezérlőket tartalmazhatja: 


90a 
90A 
90b 
90B 
90c 
god 
90H 
90I 
96j 
9om 
90M 
94p 
905 
99U 


90w 
99 W 


90x 
90Xx 
99y 
99Y 
97 


A hét napjának rövidített neve (pl. Szo) 

A hét napjának teljes neve (pl. Szomba) 

A hónap rövidített neve (pl. Feb) 

A hónap teljes neve (pl. Február) 

A dátum és idő (pl. Szo Feb 06 21:46:05 1999) 

A hónap napja [01,31] (pl. 069 

Óra [00,23] (pl. 21 

Óra [01,12] (pl. 09) 

Az év napja I001,366] (pl. 037) 

Az év hónapja [01,12] (pl. 02) 

Perc [00,59] (pl. 48) 

Délelőtt/délután (am./pm. — de./du.) jelzése a 12 órás órához (pl. PM) 
Másodperc [00,61] (pl. 48) 

Az év hete [00,53] vasárnappal kezdődően (pl. 099: az 1. hét az első va- 
sárnappal kezdődik 

A hét napja [0,6]: a 0 jelenti a vasárnapot (pl. 6) 

Az év hete [00,53] hétfővel kezdődően (pl. 099: az 1. hét az első hétfővel 
kezdődik 

Dátum (pl. 02/06/99) 

Idő (pl.21:48:40) 

Év az évszázad nélkül [00 99] (pl. 99) 

Év (pl.1999) 


Az időzóna jelzése (pl. EST), ha az időzóna ismert 
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Ezeket az igen részletes formázó szabályokat a bővíthető [/D rendszer paramétereiként 
használhatjuk, de mint minden egyedi jelölést, ezeket is célszerűbb (és kényelmesebb) csak 
eredeti feladatuk ellátására alkalmazni. 


A fenti formázó utasításokon túl a legtöbb C---változat támogatja az olyan , módosítókat" 
(modifier), mint amilyen a mezőszélességet (421.8) meghatározó egész szám (9010X). 
Az idő- és dátumformátumok módosítói nem képezik részét a C4- szabványnak, de néhány 
platformszabvány, mint a POSIX, igényelheti azokat. Következésképpen a módosítókat ne- 
héz elkerülni, még akkor is, ha nem tökéletesen , hordozhatók". 


A cctime2 vagy Ctime.h: fejállományban található — az sprintfO-hez (421.8) hasonló — 
strftimeO függvény a kimenetet az idő- és dátumformázó utasítások felhasználásával hozza 
létre: 


size t strftime(char" s, size t max, const char? format, const tm" tmp); 


A függvény legfeljebb max karaktert tesz a "tmp-ből és a format-ból a "s-be, a format for- 
mázónak megfelelően: 


int mainŐ 


( 


const int max - 20; // hanyag: abban bízik, hogy az strftimeO 
// soha sem eredményez 20-nál több karaktert 
char bujlmaxi; 
time t t — time(0); 
strftime(buf, max, "94" localtime(k 1); 
cout 2 buf; 


A fenti program az alapértelmezett classicO lokálban (§D.2.3) egy szerdai napon 
Wednesday-t fog kiírni, dán lokálban onsdag-ot. 


Azok a karakterek, melyek nem részei a meghatározott formátumnak, mint a példában az 
újsor karakter, egyszerűen bemásolódnak az első (5) paraméterbe. 


Amikor a butO azonosít egy fformátumkaraktert (és egy nem kötelező m módosítót), meg- 
hívja a do bputO virtuális függvényt, hogy az végezze el a tényleges formázást: 
do put(b,s, fill, t, fő m). 
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A put(b,s fill.t. főm) hívás a putO egyszerűsített formája, ahol a formátumkarakter (Ö és 
a módosító (m) pontosan meghatározott. Ezért a 


const char fjmtl] - "9010X; 
buxb, s, fill, t, fimt, fmtx-sizeof( fjmD); 


hívást a következő alakra lehet rövidíteni: 


butb, s, filll t, X" 109; 


Ha egy formátum többájtos karaktereket tartalmaz, annak az alapértelmezett állapotban 
(§D.4.6) kell kezdődnie és végződnie. 


A putO függvényt felhasználhatjuk arra is, hogy a Date számára lokáltól függő kimeneti mű- 
veletet adjunk meg: 


ostreamk operators(ostreamdé s, const Datek d) 


( 


ostream::sentry guard(5); // lásd §21.3.§ 
if (guard) return s; 


tm" tmp - localtimerkd.d4); 
try ( 
if (use facetz time putcchar: 2(s.getlocO) put(s,s,s.fillO,tmp, x ) failedO) 
s.setstate(ios base::failbin; 
J 
catch (...)1€ 
handle ioexception(5); // lásd §D.4.2.2 
) 


return S; 


Mivel nincs szabványos Date típus, nem létezik alapértelmezett formátum a dátumok be- és 
kivitelére. Itt úgy határoztam meg a 90x formátumot, hogy formázóként az Xx" karaktert ad- 
tam át. Mivel a get time függvény (§D.4.4.4) alapértelmezett formátuma a 96x, valószínű- 
leg ez áll legközelebb a szabványhoz. A §D.4.4.5 pontban példát is láthatunk arra, hogyan 
használhatunk más formátumokat. 
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D.4.4.4. Dátum és idő beolvasása 


Mint mindig, a bemenet , trükkösebb", mint a kimenet. Amikor érték kiírására írunk kódot, 
gyakran különböző formátumok közül választhatunk. A beolvasásnál emellett a hibákkal is 
foglalkoznunk kell és néha számítanunk kell arra, hogy számos formátum lehetséges. 


A dátum és idő beolvasását a time get jellemzőn keresztül kezeljük. Az alapötlet az, hogy 
egy lokál time get facet-je el tudja olvasni a time put által létrehozott időket és dátumokat. 
Szabványos dátum- és időtípusok azonban nincsenek, ezért a programozó egy locale-t 
használhat arra, hogy a kimenetet különféle formátumoknak megfelelően hozza létre. A kö- 
vetkező ábrázolásokat például mind létre lehet hozni egyetlen kimeneti utasítással, úgy, 
hogy a time put jellemzőt (§D.4.4.5) különböző lokálokból használjuk: 


January 15th 1999 
Thursday 15th January 1999 
15 Jan 1999AD 

Thurs 15/1/99 


A C44 szabvány arra biztat, hogy a time get elkészítésénél úgy fogadjuk el a dátum- és idő- 
formátumokat, ahogy azt a POSIX és más szabványok előírják. A probléma az, hogy nehéz 
szabványosítani a dátum és idő beolvasásának bármilyen módját, amely egy adott kultúrá- 
ban szabályos. Bölcsebb kísérletezni és megnézni, mit nyújt egy adott /ocale (§D.6[8D. Ha 
egy formátum nem elfogadott, a programozó másik, megfelelő time get facet-et készíthet. 


Az idő beolvasására használt szabványos time get a time base osztályból származik: 


class std::time base ( 


bublic: 

enum dateorder ( 
no order, // nincs sorrend, esetleg több elem is van (pl. a hét napja) 
dmy, // nap, hónap, év sorrend 
mdy, // hónap, nap, év sorrend 
ymd, // év, hónap, nap sorrend 
ydm // év, nap, hónap sorrend 

3; 


Ezt a felsorolást arra használhatjuk, hogy egyszerűsítsük a dátumformátumok elemzését. 
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A num get -hez hasonlóan a time get is egy bemeneti bejárópáron keresztül fér hozzá át- 
meneti tárához: 


template Sclass Ch, class In - istreambuf iteratorZCh: 2 
class time get : public locale::facet, public time base ( 
bublic: 

typedef Ch char. type; 

typedef In iter. type; 


explicit time get(size tr — 09; 
dateorder date orderO const f return do date orderO; ) 


// olvasás (b:e)-ből d-be, az s-beli formázási szabályok használatával; hibajelzés az r 
// beállításával: 

In get time(1n b, In e, ios baseg s, ios base::iostatek r, tm" d) const; 

In get date(1n b, In e, ios baseg s, ios base::iostateg r, tm?" d) const; 

In get yeardn b, In e, ios baseg s, ios base::iostatek r, tm?" d) const; 


In get weekday(in b, In e, ios basek s, ios base::iostatek r, tm" d) const; 
In get monthname(in b, In e, ios baseg s, ios base::iostatek r, tm" d) const; 


static locale::idid; — // facet-azonosító objektum (fD.2, §D.3, $D.3.1 
protected: 
-time getO; 


// virtuális "do " függvények a nyilvános függvények számára (lásd §D.4.1 


); 


A get timeO a do get time függvényt hívja meg. Az alapértelmezett get time a 90Xx for- 
mátum (§D.4.4) felhasználásával úgy olvassa be az időt, ahogy a lokál time putO függvé- 
nye létrehozza azt. Ugyanígy a get date0 függvény a do get dateO-et hívja meg és az alap- 
értelmezett get tiíimeO0) a 90x formátum felhasználásával (§D.4.4) a lokál time putO 
függvényének eredménye szerint olvas. 


A Date típusok legegyszerűbb bemeneti művelete valami ilyesmi: 


istream£k operator::(istreamkg s, Date d) 


( 
istream::sentry guard(5); // lásd §21.3.§ 


if (guard) return s; 


ios base::iostate res — O; 
imx-f07; 
istreambujf" iteratoráchar,char. traitsZchar: 2 end; 


1230 Függelékek és tárgymutató 


try ( 
use faceIik time gelzchar: :(s.getlocO).get date(s,end,s,res,£.Xx; 
if (res--0 1 1 res--ios base::eofbit) 
d - Date(x.tm mday, Date::Month(x.tm mon3- 1),x.tm year419009; 
else 
s.setstate(res); 
) 
catch (...) ( 
handle ioexception(5); // lásd §D.4.2.2 
) 


return S; 


A get date(s,end,s,res,£.x) hívás az istream-ről való két automatikus átalakításon alapul: az 
első s paraméter egy istreambuf iterator létrehozására használatos, a harmadik paraméter- 
ként szereplő s pedig az istream bázisosztályára, az ios base-re alakul át. 


A fenti bemeneti művelet azon dátumok esetében működik helyesen, amelyek a time ttí- 
pussal ábrázolhatók. 


Egy egyszerű próba a következő lenne: 


int mainŐ 

try ( 
Date today; 
cout ££ today cz endi; // írás 90x formátummal 
Date d(12, Date::may, 1999); 


cout cz d c£ endi; 

Date dd; 

while (cin 5: dd) cout c£ dd c£ endi; // az 90x formátummal létrehozott 
// dátumok olvasása 


j 


catch (Date::Bad date) f 
cout c£ "Rossz dátum: a program kilépMm"; 


J 


A put time byname változata (§D.4, §D.4.1) szintén adott: 


template cclass Ch, class Out - ostreambujf iteratorzCh: : 
class std::time put byname : public time putZCh, Out: €/. ... ?/); 
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D.4.4.5. Egy rugalmasabb Date osztály 


Ha megpróbálnánk felhasználni a §D.4.4.2 pontból a Date osztályt a §D.4.4.3-ban és 
SD.4.4.4-ben szereplő be- és kimenettel, hamarosan korlátokba ütköznénk: 


1. A Date csak olyan dátumokat tud kezelni, amelyek a time ttípussal ábrázolha- 
tók: ez általában az [1970,2038] tartományt jelenti. 

2. A Date csak a szabványos formátumban fogadja el a dátumokat — bármilyen le- 
gyen is az. 

3. A Date-nél a bemeneti hibák jelzése elfogadhatatlan. 

4. A Date csak char típusú adatfolyamokat támogat, nem tetszőleges karakter 
típusúakat. 


Egy hasznosabb bemeneti művelet a dátumok szélesebb tartományát fogadná el, felismer- 
ne néhány gyakori formátumot és megbízhatóan jelentené a hibákat valamilyen jól használ- 
ható formában. Ahhoz, hogy ezt elérjük, el kell térnünk a time t ábrázolástól: 


class Date ( 
bublic: 
enum Month f jan-1, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec ) ; 


struct Bad date f 
const char? why; 
Bad date(const char? p) : why(p) ( ) 


3 

Date(int dd, Month mm, int yy, int day of week - 09; 

DateO; 

void make tm(tm" t) const; // a Date tm ábrázolását "t-be teszi 
time t make time tO const; // a Date time t ábrázolásával tér vissza 


int yearO const f return 9; ) 
Month monthO const f return m; ) 
int dayO const f return d; ) 
VBA 
brivate: 
char d; 
Month m; 
int y; 


); 


Itt az egyszerűség kedvéért a (d,m,y) ábrázoláshoz (410.2) tértünk vissza. 
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A konstruktort így adhatjuk meg: 


Date:: Date(int dd, Month mm, int yy, int day of week) 
: d(dd), m(mm), y(wy) 


( 
if (d--0 k.k m--Month(0) k.£ y--0) return; // Date(0,0,0) a "null dátum" 
if (nmxsjan 11 decsmm) throw Bad date( "rossz a hónap"); 
if (dds1 11 31cdd) // jócskán leegyszerűsítve; lásd §10.3.1 


throw Bad date( rossz a hónap napja"; 
if (day of week kk day in week(yy,mm,dd)!/-day of week) 
throw Bad date( rossz a hét napja"); 


J 


Date::DateO : d(0), m(0), y(0) £ ) // egy "null dátum" 


A day in weekO kiszámítása nem könnyű és nem kapcsolódik a lokálokhoz, ezért kihagy- 
tam. Ha szükségünk van rá, rendszerünkben biztosan megtalálhatjuk valahol. 


Az összehasonlító műveletek mindig hasznosak az olyan típusok esetében, mint a Date: 


bool operator-—(const Datek x, const Dateg y) 


( 
return x.yearO--y.yearO £.£ x.monthO--y.monthO ££ x.dayO--y.dayO; 


j 


bool operator!1-(const Datekg x, const Dateg y) 
( 
return K(x--y); 


j 


Mivel eltértünk a szabványos ím és time t formátumoktól, szükségünk van konverziós 
függvényekre is, amelyek együtt tudnak működni azokkal a programokkal, amelyek eze- 
ket a típusokat várják el: 


void Date::make tm(tim" p) const // a dátum "p-be helyezése 
( 

imx7-f0)7; 

tp - Xg 

b-tm year -— y-1900; 

b-xtm mday -— d; 

b-tm mon — m-I[; 


j 


time t Date::make time tO const 


( 
if (yc1970 11 20382y) // túlegyszerűsített 
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throw Bad date("A dátum a time t tartományán kívül esik."); 
tm x; 
make tm(£x); 
return mktime(dtz x); 


D.4.4.6. Dátumformátumok megadása 


A C44 nem határozza meg a dátumok kiírásának szabványos formátumát (a 90x közelíti meg 
a legjobban; §D.4.4.3), de még ha létezne is ilyen, valószínűleg szeretnénk más formátumo- 
kat is használni. Ezt úgy tehetjük meg, hogy meghatározunk egy , alapértelmezett formátu- 
mot" és lehetőséget adunk annak módosítására: 


class Date format f 
static char fmtll; . / alapértelmezett formátum 
const char? curr; // az épben érvényes formátum 
const char? curr. end; 
bublic: 
Date formatoÓ : curr(fmt), curr. end(fmtastrlenrfmD) f ? 


const char?" beginŐ const f return curr; ) 
const char? endO const f return curr. end; ) 


void set(const char" p, const char? ag) f curr-p; curr. end-g; ) 
void set(const char? p) ( curr-p; curr. end-curráistrlen(D9; ) 


static const char? default fmtO f return fmt; ) 


J; 
const char Date formatáchar?::fmtlj - "90A, 90B 90d, 99Y"; // pl. Friday, February 5, 1999 


Date format date fmt; 


Hogy az stirftimeO formátumot (§D.4.4.3) használhassuk, tartózkodtam attól, hogy 
a Date format osztályt a használt karaktertípussal paraméterezzem. Ebből következik, hogy 
ez a megoldás csak olyan dátumjelölést enged meg, amelynek formátumát ki lehet fejezni 
a char] típussal. Ezenkívül felhasználtam egy globális formátum-objektumot is (date fmD, 
az alapértelmezett dátumformátum megadásához. Mivel a date fmtértékét meg lehet változ- 
tatni, a Date formázásához rendelkezésünkre áll egy — meglehetősen nyers — módszer, ha- 
sonlóan ahhoz, ahogy a giobalÓ lokált (§D.2.3) lehet használni a formázásra. 
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Sokkal általánosabb megoldás, ha létrehozzuk a Date in és Date out facet-eket az adatfo- 
lyamból történő olvasás és írás vezérléséhez. Ezt a megközelítést a §D.4.4.7 pontban mutat- 
juk be. Ha adott a Date format, a Date::oberatorSSO-t így írhatjuk meg: 


templatezclass Ch, class Tr: 
basic ostreamZCh,Tr-:k operatorzz(basic ostreamzCh,Tr:£k s, const Datek d) 
// írás felhasználói formátummal 
( 
typename basic ostreamzCh, Tr2::sentry guard(5); // lásd §21.3.§ 
if (guard) return s; 


tm t; 

d.make tm(£W); 

try f 
const time pulZCh:k f - use facetis time putzCh: 2(s.getlocO; 
if fputcs,s,s IO,kt, date fmt.beginO, date fmt.endO) failedO) 

s.setstate(ios base::failbiD; 

) 

catch (...) ( 
handle ioexception(5); // lásd SD.4.2.2 

) 


return S; 


A has facet függvénnyel ellenőrizhetnénk, hogy az s lokálja rendelkezik-e a time putcCh: 
jellemzővel, itt azonban egyszerűbb úgy kezelni a problémát, hogy minden kivételt elka- 
punk, amit a use facet kivált. 


Íme egy egyszerű tesztprogram, ami a kimenet formátumát a date fimt-n keresztül vezérli: 


int mainŐ 
try( 
while (cin 22 dd ££ dd !- DateO) cout cz dd c£ endi; // írás az alapértelmezett 
// date fmt használatával 


date fmt.set("99Y/9om,/90d"); 


while (cin 32 dd kk dd !- DateO) cout cz dd c£ endi; // írás az "99Y/9om/9od" 


// használatával 


J 


catch (Date::Bad date e) f 
cout 22 "Rossz dátum: " c£ e.why cz endi; 


J 
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D.4.4.7. Bemeneti facet-ek dátumokhoz 


Mint mindig, a bemenet kezelése kicsit nehezebb, mint a kimeneté. Mégis, mivel 
a get date0 javított a felületen az alacsonyszintű bemenethez és mert a §D.4.4.4 pontban 
a Date típushoz megadott operator: nem fért hozzá közvetlen módon a Date ábrázolá- 
sához, az operator: -t változatlanul használhatjuk. Íme az oberator2?0 sablon függvény- 
ként megírt változata: 


templatexclass Ch, class Tr: 
istreamzCh, Ir-£ operator:?(istreamzZCh,Tr-:k s, Datek d) 


( 
typename istreamzZCh, Tr2::sentry guard(5); 
if (guard) try ( 
ios base::iostate res — O; 
tmx-f07; 
istreambuf iteratorzCh, Tr: end; 
use facetk time gelzCh: :(s.getlocO0).get date(s,end,s,res,k.X); 
if (res--0 11 res--—ios base::eofbit) 
d - Date(x.tm mday, Date::Month(x.tm mon41),x.tm yeart1900,x.tm wday); 
else 
s.setstate(res); 
j 
catch (...)( 
handle ioexception(59; // lásd §D.4.2.2 
j 
return s; 
J 


Ez a bemeneti művelet az istream time get jellemzőjének get date függvényét hívja meg, 
így a bemenet új, rugalmasabb formáját adhatjuk meg, úgy, hogy származtatással egy új 
Jfacet-et készítünk a time get-ből: 


templatecxcilass Ch, class In -— istreambuf iteratorzCh: - 
class Date in : public std::time getlzCh, In: ( 


public: 

Date inCsize tr - 0) : std::time getZChx(7) ( ) 
brotected: 

In do get date(in b, In e, ios baseg s, ios base::iostatek r, tm" tmp) const; 
Dbrivate: 


enum Vtype ( novalue, unknown, dayofweek, month ); 
In getvaldn b, In e, ios baseg s, ios base::iostateg r, int?" v, Vtype" res) const; 


Vö 
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A getval0 függvénynek egy évet, egy hónapot, a hónap napját és a hét egy napját kell be- 
olvasnia (ez utóbbi nem kötelező), az eredményt pedig egy ím szerkezetbe kell tennie. 


A hónapok és a hét napjainak nevei a lokáltól függnek, következésképpen nem említhet- 
jük meg azokat közvetlenül a bemeneti függvényben. Ehelyett a hónapokat és napokat úgy 
ismerjük fel, hogy meghívjuk azokat a függvényeket, amelyeket a time get ad erre a célra: 
a get monthnameg és get weekdayO függvényeket (§D.4.4.4). 


Az év, a hónap napja és valószínűleg a hónap is egészként van ábrázolva. Sajnos egy szám 
nem jelzi, hogy egy hónap napját jelöli-e vagy valami egészen mást. A 7 például jelölhet jú- 
liust, egy hónap 7. napját vagy éppen a 2007-es évet is. A time get date orderŐ függvényé- 
nek valódi célja az, hogy feloldja az efféle többértelműségeket. 


A Date inértékeket olvas be, osztályozza azokat, majd a date orderO függvénnyel megné- 
zi, a beírt adatok értelmesek-e (illetve , hogyan értelmesek"). A tényleges olvasást az adat- 
folyam átmeneti tárából, illetve a kezdeti osztályozást a privát getvalO függvény végzi: 


templatexclass Ch, class In: 
In Date inzCh, In:::getval(In b, In e,ios baseg s,ios base::iostatek r,int" v, Vtybe" res) 


const 
// A Date részének olvasása: szám, a hét napja vagy hónap. Üreshelyek és írásjelek átlépése. 
( 
const ctypezCh2k ct - use facet£ ctypezCh: (s .getlocO); // a ctype leírását 
// lásd §D.4.5.-ben 
Ch c; 
res - novalue; // nem talált értéket 
for G)( // üreshelyek és írásjelek átlépése 
if (b -—- e) return e; 
c — tb; 
if (((ct.is(ctype base::space,c) 1 1 ct.is(ctype base::punct,c))) break; 
F4D; 
, 
if (ct.is(ctype base::digit,C)) ( / egész olvasása a numpunct figyelmen kívül hagyásával 
inti — 0; 
do ( // tetszőleges karakterkészlet számjegyének decimális értékké alakítása 


static char const digits[] - "70123456789"; 
i - 1710 4 find(digits, digits4 10,ct.narrou(Cc," "))-digiíts; 
c — £44b; 

? while (ct.is(ctype base::digit,cC)); 


kp — [/ 
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tres - unknown; // egy egész, de nem tudjuk, mit ábrázol 
return b; 

J 

if (ct.is(ctype base::albha,c)) f // hónap nevének vagy a hét napjának keresése 
basic stringZCh: str; 


while (ct.is(ctype base::alpha,c)) ( // karakterek olvasása karakterláncba 
SÍT 47 CG; 
if Gb -- e) break; 
c— tb; 

j 

tm t; 

basic stringstreamzCh: ss(Str); 

typedef istreambuf iteratorzCh: SI; // bejárótípus az ss átmeneti tárához 


get monthnamecss.rdbufO,SIO,s,r,£ 1; // olvasás memóriabeli adatfolyam 
// átmeneti tárából 


if ((ríC(ios base::badbitlios base::failbit))--0) f 
£p- t.tm mon; 
tres - month; 


return b; 
j 
r- 0; // az adatfolyam-állapot törlése a második olvasás előtt 
get weekday(Css.rdbufO,SIO,s,T, 61; // olvasás memóriabeli adatfolyam 


// átmeneti tárából 
if (GríCios base::badbit lios base::failbit))--0) f 
kp -ttm wday; 
Xres - dayofweek; 
return b; 


j 
J 


r 1— ios base::failbit; 
return b; 


Itt a trükkös" rész a hét napjainak és a hónapoknak a megkülönböztetése. Mivel bemene- 
ti bejárókon keresztül olvasunk, nem olvashatjuk be /b,eJ-t kétszer, először egy hónapot, 
másodszor pedig egy napot keresve. Másfelől nem tudjuk megkülönböztetni a hónapokat 
sem a napoktól, ha egyszerre csak egy karaktert olvasunk be, mert csak 
a get monthnameg és a get weekdayO függvények tudják, hogy az adott lokálban a hóna- 
pok és a hét napjainak nevei mely karaktersorozatokból épülnek fel. Azt a megoldást vá- 
lasztottam, hogy az alfabetikus karakterekből álló sorozatokat beolvastam egy karakterlánc- 
ba, ebből egy szíringstream-et készítettem, majd ismételten olvastam az adatfolyam 
streambujf-jából. 
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A hibajelző rendszer közvetlenül használja az olyan állapotbiteket, mint az ios base::badbit. 
Ez azért szükséges, mert az adatfolyam állapotát kezelő kényelmesebb függvényeket, mint 
a clearÓ és a setstateO, a basic ios osztály határozza meg, nem pedig annak bázisosztálya, 
az ios base (§21.3.39. Ha szükséges, a 55 operátor felhasználja a get dateŐ által jelentett hi- 
bákat, hogy visszaállítsa a bemeneti adatfolyam állapotát. 


Ha a getvalO adott, először beolvashatjuk az értékeket, majd később megnézhetjük, hogy 
értelmesek-e. A dateorderO szerepe döntő lehet: 


templatexclass Ch, class In: 
In Date inzZCh, In:::do get date(1n b, In e, ios basek s, ios base::iostatek r, tm" tmp) const 
// a "hét napja" (nem kötelező), melyet md, dmy, mdy, vagy ydm formátum követ 
( 
int val[3]; // nap, hónap, és év értékek számára 
Vtype res[3/] - ( novalue ?; // értékosztályozáshoz 


for (int i-0; b/-ekk iS3; 1410)€  — / nap, hónap, év beolvasása 
b - getval(b,e,s,r,£ valfil,£ resli)); 
if (9) return b; // hoppá: hiba 
if (resliJ--novalue) (f , / nem tudjuk befejezni a dátumot 
r 1— ios base::badbit; 
return b; 
) 
if (resliJ--dayofweeRk) ( 
tmp-:tm wday — vallij; 
--i; , / hoppá: nem nap, hónap, vagy év 


) 
, 


time base::dateorder order - dateorderO; — // most megpróbálunk rájönni 
// a beolvasott adat jelentésére 


if (res[0] -- month) f // mdy formátum vagy hiba 
VASS 

f 

else if (res[1] -- month) ( // dmy vagy ymd vagy hiba 
tImp-2tm mon - val[[1]; 
switch (order) 


( 

case dmy: 
tmp-:tm mday — val[[0j; 
tmp-:tm year - val[2]; 
break; 

case ymd: 


tmp-:tm year - va[[0]; 
tmp-:tm mday —- va[[1]; 
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break; 
default: 
r 1— ios base::badbit; 
return b; 
J 
J 
else if (res[2] -- month) ( // ydm vagy hiba 
Zs 
j 


else ( // megbízunk a dateorder-ben vagy hiba 
lee 
J 


tmp--tm year -- 1900; // az alapév igazítása a tm-hez 
return b; 


Azokat a kódrészleteket, amelyek nem járulnak hozzá a lokálok, dátumok és a bemenet ke- 
zelésének megértéséhez, kihagytam. A jobb és általánosabb dátumformátumok beolvasásá- 
ra alkalmas függvények megírását feladatként tűztem ki (4D.6[9-10). 


Íme egy egyszerű tesztprogram: 


int mainŐ 

try ( 
cin.imbue(loc(iocaleO, new Date in)); // dátumok olvasása a Date in használatával 
while (cin 32 dd k£ dd !- DateO) cout c£ dd c£ endl; 

74 

catch (Date::Bad date e) ( 


cout 2 "Rossz dátum: " SZ e.why cz endl; 


j 


Vegyük észre, hogy a do get dateO értelmetlen dátumokat is elfogad, mint amilyen a 


Thursday October 7, 1998 
és az 
1999/Feb/31 


Az év, hónap, nap és (nem kötelezően) a hét napja egységességének ellenőrzése a Date 
konstruktorában történik. A Date osztálynak kell tudnia, mi alkot helyes dátumot, a Date in 
osztállyal pedig nem kell megosztania ezt a tudást. 
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Meg lehetne oldani azt is, hogy a get valÓ vagy a get date0 függvények próbálják kitalál- 
ni a számértékek jelentését. Például a 


12 May 1922 


világos, hogy nem a 12-es év 1922. napja. Azaz , gyaníthatnánk", hogy egy olyan számérték, 
ami nem lehet a megadott hónap napja, biztosan évet jelöl. Az ilyen feltevések bizonyos 
esetekben hasznosak lehetnek, de nem jó ötlet ezeket általánosabb környezetben használ- 
ni. Például a 


12 May 15 


a 12., 15., 1912.,1915., 2012., vagy 2015. évben jelölhet egy dátumot. Néha jobb megköze- 
lítés, ha kiegészítjük a jelölést valamivel, ami segít az évek és napok megkülönböztetésé- 
ben. Az angolban a 1" és 15" például biztosan egy hónap napjait jelölik. Ugyanígy 
a 751BC-t és az 1I453AD-t G.e.751 és i.sz.1453) nyilvánvalóan évként lehetne azonosítani. 


D.4.5. Karakterek osztályozása 


Amikor a bemenetről karaktereket olvasunk be, gyakran van szükség arra, hogy osztályoz- 
zuk azokat, hogy értelmezhessük, mit is olvastunk. Egy szám beolvasásához például egy 
bemeneti eljárásnak tudnia kell, hogy a számjegyeket mely karakterek jelölik. A §6.1.2 pont- 
ban is bemutattuk a szabványos karakterosztályozó függvények egy felhasználását a beme- 
net elemzésére. 


Természetesen a karakterek osztályozása függ az éppen használatos ábécétől. Ezért rendelke- 
zésünkre áll a ctype jellemző, amely az adott lokálban a karakterek osztályozását ábrázolja. 


A karakterosztályokat a mask felsoroló típus határozza meg: 


class std::ctype base ( 


bublic: 
enum mask ( // a tényleges értékek megvalósításfüggőek 
space — 1, // üreshely (a "C" lokálban "? ?, Nm, MM, ..J 
brint - 1221, // nyomtatható karakterek 
cntrl - 122, // vezérlőkarakterek 
upper - 1223, // nagybetűk 
lower - 1224, // kisbetűk 
alpha - 1205, // alfabetikus karakterek 
digit - 1226, // decimális számjegyek 


bunct - 1227, // írásjelek 


D. Helyi sajátosságok 1241 


xdigit - 1228, // hexadecimális számjegyek 
alnumzalphaldigit, — // alfanumerikus karakterek 
graphz-alnum Ipunct 


Fő 
Ji 


A mask nem függ egyetlen karaktertípustól sem, következésképpen a felsorolás egy (nem 
sablon) bázisosztályban található. 


Világos, hogy a mask a hagyományos C és C-r--beli osztályozást tükrözi (420.4.1). Eltérő ka- 
rakterkészletek esetében azonban a különböző karakterértékek különböző osztályokba es- 
nek. Az ASCII karakterkészletben például a 125 egész érték a 2" karaktert jelöli, ami az írás- 
jelekhez (puncD) tartozik, a dán karakterkészletben viszont az 4" magánhangzót, amit egy 
dán locale-ben az alpha osztályba kell sorolni. 


Az osztályozást , maszknak" nevezik, mert a kis karakterkészletek hagyományos és haté- 
kony osztályozása egy táblával történik, amelyben minden bejegyzés az osztály(Coka)t ábrá- 
zoló biteket tárolja: 


table a7 -- lower lalpha I.xdigit 
table[ 17 —— digit 
table[" 7 -—- space 


Ha a fenti adott, a tablelcjk m nem nulla, ha a c karakter az m osztályba tartozik ( c egy m"), 
egyébként pedig O. 


A ctype definíciója így fest: 


template Sclass Ch: 
class std::ctype : public locale::facet, public ctype base f 
bublic: 

typedef Ch char. type; 

explicit ctype(size tr - 09; 


bool is(mask m, Ch c) const; . // "c" az "m" osztályba tartozik? 


// minden [(b:e)-beli Ch osztályozása, az eredmény a v-be kerül 
const Ch" is(const Ch? b, const Ch" e, mask" v) const; 


const Ch" scan is(mask m, const Ch? b, const Ch" e) const;  // m keresése 
const Ch? scan not(rmask m, const Ch" b, const Ch" e) const; // nem m keresése 
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Ch toupper(Ch c) const; 

const Ch" toupper(Ch" b, const Ch" e) const; // [b:e) átalakítása 
Ch tolowe1(Ch c) const; 

const Ch" tolower(Ch" b, const Ch" e) const; 


Ch widen(char c) const; 

const char? widen(const char? b, const char? e, Ch" b2) const; 

char narrou(Ch c, char def) const; 

const Ch?" narrou(const Ch? b, const Ch" e, char def; char? b2) const; 


static locale::id id; // facet-azonosító objektum (fD.2, $D.3, §D.3.1 
brotected: 
actypeO; 


// virtuális "do " függvények a nyilvános függvények számára (lásd §D.4.1) 


J; 


Az is(c,m) hívással vizsgálhatjuk meg, hogy a c karakter az m osztályba tartozik-e: 


int count spaces(const string s, const localekg loc) 


( 
const ctlypeschar:k ct — use facetlk ctypezchar: (loc); 
inti — 0; 
forcstring::const iterator p - s.beginO; p !- s.endO; 43p) 
if (ct.is(ctype base::space,"p)) ti; // üreshely a ct meghatározása alapján 
return i; 


Az isŐ függvénnyel azt is megnézhetjük, hogy egy karakter adott osztályok valamelyikébe 
tartozik-e: 


ct.is(ctype base::space Ictype base::bunct,cC); — // c üreshely vagy írásjel ct alapján? 


Az is(b,e,v) hívás a /b,eJ-ben szereplő minden karakter osztályát eldönti és a megfelelő po- 
zícióra helyezi azokat a v tömbben. 


A scan is(m,b,e) egy mutatót ad vissza a /b,eJ-ben lévő első olyan karakterre, amely az m 
osztályba tartozik. Ha egyetlen karakter sem tartozik az m osztályba, a függvény az e-t ad- 
ja vissza. Mint mindig a szabványos facet-ek esetében, a nyilvános tagfüggvény saját , do " 
virtuális függvényét hívja meg. Egy egyszerű változat a következő lenne: 


D. Helyi sajátosságok 1243 


template Sclass Ch: 
const Ch" std::ctybezCh:::do scan is(mask m, const Ch" b, const Ch" e) const 


( 
while (b!-e k.£ !Jis(m,?"b)) 4--b; 
return b; 


J 


A scan not(m, b,e) a (b,eJ-ben lévő első olyan karakterre ad vissza mutatót, amely nem tar- 
tozik az m osztályba. Ha minden karakter az m osztályba tartozik, a függvény az e-t adja 
vissza. 


A touppeic) a c nagybetűs változatát adja vissza, ha az létezik a használatban lévő karak- 
terkészletben; különben pedig magát a c-t. 


A touppertb,e) a /b,e) tartományban minden karaktert nagybetűsre alakít és az e-t adja 
vissza. Ennek egy egyszerű megvalósítása a következő lehet: 


template Sclass Ch: 
const Ch" std::ctybezCh:::to upper(Ch? b, const Ch" e) 
( 

for C ; b!-e; 44b) "b - touppberC b); 

return e; 


J 


A tolowerO függvények hasonlóak a toupperO-hez, azzal az eltéréssel, hogy kisbetűsre ala- 
kítanak. 


A widenCC) a c karaktert a neki megfelelő C/ típusú értékre alakítja. Ha a Ch karakterkész- 
lete több c-nek megfelelő karaktert nyújt, a szabvány ,a legegyszerűbb ésszerű átalakítás" 
alkalmazását írja elő. Például a 


wcout ££ use facetk ctybezwchar. 12 x(wcout.getlocO).widenC e; 


az e karakternek a wcout lokálban lévő ésszerű megfelelőjét fogja kiírni. 


A különböző karakterábrázolások, mint az ASCII és az EBCDIC közötti átalakítást szintén el 
lehet végezni a widenO függvénnyel. Például tegyük fel, hogy létezik az ebcdic lokál: 


char EBCDIC e - use facetK ctypezchar: r(ebcdic).widen(C e"; 


A widen(b,e,v) hívás a /b,e) taetományban lévő minden karakter , szélesített" változatát he- 
lyezi a megfelelő pozícióra a v tömbben. 
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A narrou(ch, def) egy chartípusú értéket ad a Chtípusú c/ karakternek. Itt is a , legegysze- 
rűbb ésszerű átalakítást" kell alkalmazni. Ha nem létezik megfelelő char típusú érték, 
a függvény a def-et adja vissza. 


A narrow(b,e,v) hívás a /b,e) tartományban lévő minden karakter , leszűkített" változatát he- 
lyezi a megfelelő pozícióra a v tömbben. 


Az általános elgondolás az, hogy a narrowO a nagyobb karakterkészletet alakítja egy ki- 


sebbre, míg a widenO ennek ellenkezőjét végzi. Egy kisebb karakterkészletben szereplő c 
karakter esetében elvárnánk a következőt: 


c -- narrow(widen(c), 0)  // nem garantált 


Ez akkor igaz, ha a c által ábrázolt karakternek csak egyetlen jelölése van a , kisebbik" ka- 
rakterkészletben, ez azonban nem biztos. Ha a char típussal ábrázolt karakterek nem ké- 
pezik részhalmazát azoknak, amelyeket a nagyobb (CD) karakterkészlet ábrázol, rendelle- 
nességekre és problémákra számíthatunk a karaktereket általánosságban kezelő 
programokban. 


A nagyobb karakterkészletben lévő c/ karakterre ugyanígy elvárnánk az alábbit: 


widen(narrou(ch, def)) -—- ch 1 I widen(narrou(ch, def)) -——- widen(def) / nem garantált 


Ez gyakran teljesül, de a nagyobb karakterkészletben több értékkel jelölt karakterek eseté- 
ben nem mindig biztosítható, hogy csak egyszer legyenek ábrázolva a kisebbik készletben. 
Egy számjegynek (pl. a 7-nek) például gyakran több eltérő ábrázolása létezik egy nagy ka- 
rakterkészletben. Ennek jellemzően az az oka, hogy egy nagy karakterkészletnek általában 
számos hagyományos karakterkészlet-részhalmaza van és a kisebb karakterkészletek ka- 
raktereiből másodpéldányok léteznek, hogy megkönnyítsék az átalakítást. 


Az alap karakterkészletben (4C.3.3) szereplő minden karakterre biztosított a következő: 
widen(narrou(ch lit,0)) —— ch lit 
Például: 


widen(narrou( x )) -— x 
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A narrouO és widenŐ függvények mindenütt figyelembe veszik a karakterek osztályozá- 
sát, ahol lehetséges. Például ha is(albha,c) igaz, akkor az is(albha,narrouc(c, a )) és az 


is(alpha, widen(c)) is igaz lesz ott, ahol az albha érvényes maszk a használatban lévő lokál- 
ra nézve. 


A ctybe facet-et — különösen a narrowO és widenO függvényeket — általában arra használ- 
juk, hogy olyan kódot írjunk, amely tetszőleges karakterkészleten végzi a be- és kimenet, 
illetve a karakterláncok kezelését; azaz, hogy az ilyen kódot általánossá tegyük a karakter- 
készletek szempontjából. Ebből következik, hogy az iostream-megvalósítások alapvetően 
függnek ezektől az eszközöktől. A felhasználónak legtöbbször nem kell közvetlenül hasz- 
nálnia a ctype jellemzőt, ha az Ciostream:-re és a cstring:-re támaszkodik. 


A ctype byname változata (§D.4, §D.4.1) szintén adott: 


template cclass Ch: class std::ctype byname : public ctypezCh: f€ /£ ... "/); 


D.4.5.1. Kényelmet szolgáló felületek 


A ctybe facet-et leggyakrabban arra használjuk, hogy lekérdezzük, hogy egy karakter egy 
adott osztályba tartozik-e. Következésképpen erre a célra a következő függvények adottak: 


template Sclass Ch: bool isspace(Ch c, const localekg loc); 
template class Ch: bool isprint(Ch c, const localegt loc); 
template class Ch: bool iscntrk(Ch c, const locale loc); 
template class Ch: bool isuppex(Ch c, const locale loc); 
template Sclass Ch: bool islower(Ch c, const localek loc); 
template class Ch: bool isalbha(Ch c, const localek loc); 
template class Ch: bool isdigit(Ch c, const localek loc); 
template class Ch: bool ispunck(Ch c, const locale loc); 
template class Ch: bool isxdigit(Ch c, const localek loc); 
template class Ch: bool isalnum(Ch c, const localek loc); 
template class Ch: bool isgraph(Ch c, const localeg loc); 


A fenti függvények a use facet-et használják: 
template cclass Ch: 
inline bool isspace(Ch c, const localekg loc) 
( 
J 


return use facetk ctypezCh: (loc).is(space, c); 
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Ezen függvények egyparaméterű változatai (420.4.2) az aktuális C globális lokálhoz, nem 
a Cs globális lokáljához, a /ocale0-hez készültek. Azokat a ritka eseteket kivéve, amikor 
a C és a Cst globális lokál különbözik (§D.2.3), ezeket a változatokat úgy tekinthetjük, 
mintha a kétparaméterű változatokat a locale0-re alkalmaztuk volna: 


inline int issbace(int i) 


( 
return isspaceGi, locale0);  // majdnem 


J 


D.4.6. Karakterkód-átalakítások 


A fájlban tárolt karakterek ábrázolása néha különbözik ugyanazoknak a karaktereknek az 
elsődleges memóriában kívánatos ábrázolásától. A japán karaktereket például gyakran 
olyan fájlokban tárolják, amelyekben , léptetések" jelzik, hogy az adott karaktersorozat 
a négy legelterjedtebb karakterkészlet (kandzsi, katakana, hiragana és romadzsi) közül me- 
lyikhez tartozik. Ez kissé esetlen megoldás, mert minden bájt jelentése a , léptetési állapot- 
tól" függ, de memóriát takaríthat meg, mert csak egy kandzsi karakter ábrázolása igényel 
egy bájtnál többet. Az elsődleges memóriában ezek a karakterek könnyebben kezelhetők, 
ha többájtos karakterként ábrázoltak, ahol minden karakter mérete megegyezik. Az ilyen 
karakterek (például a Unicode karakterek) általában széles karakterekben vannak elhelyez- 
ve (wchar. t; §4.3). Mindezek miatt a codecut facet eszközöket nyújt a karakterek egyik áb- 
rázolásról a másikra való átalakítására; miközben azokat olvassuk vagy írjuk: 





Ábrázolás lemezen: 
JIS 











A codectt által felügyelt I/O átalakítások 





Unicode 











Ábrázolás az elsődleges memóriában: 
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Ez a kódátalakító rendszer elég általános ahhoz, hogy a karakterábrázolások között tetsző- 
leges átalakítást tegyen lehetővé, így a bemeneti adatfolyamok által használt /ocale beállítá- 
sával olyan programot írhatunk, amely (char, wchar. t vagy más típusban tárol) alkalmas 
belső karakterábrázolást használ és többféle karakter-adatfolyam ábrázolást elfogad beme- 
netként. A másik lehetőség az lenne, hogy magát a programot módosítjuk vagy a beolva- 
sott és kiírt fájlok formátumát alakítjuk oda-vissza. 


A codecut a különböző karakterkészletek közötti átalakításra akkor ad lehetőséget, amikor 
a karaktert az adatfolyam átmeneti tára és egy külső tár között mozgatjuk: 


class std::codecuvt base f 
bublic: 
enum result f ok, partial, error, noconu9; — // eredményjelző 


); 


template cclass I, class E, class State: 
class std::codecut : public locale::facet, public codecut base f 
public: 

typedef I intern type; 

typedef E extern type; 

typedef State state type; 


explicit codecut(size tr - 09; 


result in(Stateg, const E" from, const E?" from end, const E?£k from next, // olvasás 
TF to, Tt to end, FF to next) const; 

result out(Statek, const T" from, const FT" from end, const F£ from next, // írás 
E" to, E" to end, E?£ to next) const; 


result unshift(Statek, E" to, E? to end, E"?£ to next) const; // karaktersorozat vége 


int encodingO const throwO; // alapvető kódolási tulajdonságok 
bool always noconyO const throwO; // mehet az I/O kóődátalakítás nélkül? 


int length(const Statek, const E" from, const E" from end, size t max) const; 
int max lengthO const throwO;  //a lehetséges legnagyobb lengthO 


static locale::id id; // facet-azonosító objektum (fD.2, $D.3, §D.3.1) 
brotected: 
-codecutO; 


// virtuális "do " függvények a nyilvános függvények számára (lásd SD.4.1 
j; 
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A codecut facet-et a basic filebuf(§21.5) karakterek olvasásához és írásához használja és az 
adatfolyam lokáljából olvassa ki (421.7.1. 


A State sablonparaméter az éppen átalakított adatfolyam léptetési állapotának tárolására 
szolgáló típus. Ha specializációt készítünk belőle, a State-et a különböző átalakítások azo- 
nosítására is felhasználhatjuk. Ez utóbbi azért hasznos, mert így többfajta karakterkódolás- 
hoz (karakterkészlethez) tartozó karaktereket lehet ugyanolyan típusú objektumokban 
tárolni: 


class JiSstate €/§ .. "/ 3; 
b - new codecviZwchar. t,char,mbstate t2z;  // szabványos char-ról széles karakterre 
g - new codecvizwuchar. t char JiSstate2; // JIS-ről széles karakterre 


A különböző State paraméterek nélkül a facet nem tudná megállapítani, melyik kódolást té- 
telezze fel egy adott char adatfolyamra. A rendszer szabványos átalakítását a char és 
a wchar. ttípusok között a ccwchar: vagy Cwchar.h: fejállományban lévő mbstate ttípus 
írja le. 


Származtatott osztályként, névvel azonosítva új codecut-t is létrehozhatunk: 


class JiScut : public codecvutéwchar. t,char,mbstate t2€/5 ... "/); 


Az in(sfromjrom endjfrom next, to,to end,to next) hívás minden karaktert beolvas 
a [from from nex? tartományból és megpróbálja átalakítani azokat. Ha egy karakterrel vég- 
zett, akkor azt új alakjában a /to,to end) tartomány megfelelő helyére írja; ha átalakításra 
nem kerül sor, a függvény ezen a ponton megáll. A visszatéréskor az inŐ a from next-ben 
az utolsó beolvasott karakter utáni pozíciót, a to next-ben pedig az utolsó írott karakter utá- 
ni pozíciót tárolja. Az inO által visszaadott result érték jelzi, hogy a függvény mennyire tud- 
ta elvégezni a munkát: 


ok: A [from from end) tartományban minden karakter átalakításra került. 
partial. A [from from end) tartományban nem minden karakter került átalakításra. 
error: Az outO olyan karakterrel találkozott, amit nem tudott átalakítani. 
NOCONL: Nem volt szükség átalakításra. 


A partial (részleges) átalakítás nem biztos, hogy hiba. Elképzelhető, hogy több karaktert 
kell beolvasni, mielőtt egy többájtos karakter teljes lesz és ki lehet írni, esetleg a kimeneti 
átmeneti tárat kell kiüríteni, hogy helyet csináljunk a további karaktereknek. 
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A bemeneti karaktersorozat állapotát az in 0) meghívásának kezdetén a Szate típusú s para- 
méter jelzi. Ennek akkor van jelentősége, ha a külső karakterábrázolás léptetési állapotokat 
használ. Jegyezzük meg, hogy az s (nem konstans) referencia paraméter: a hívás végén 
a bemeneti sorozat léptetésének állapotát tárolja, ami lehetővé teszi, hogy a programozó 
kezelhesse a részleges átalakításokat és hosszú sorozatokat is átalakíthasson az in több- 
szöri meghívásával. Az out(s from from end from next to,to end,to next) ugyanúgy ala- 
kítja át a [from from end)J-et a belső ábrázolásról a külsőre, ahogy az inŐ a külső ábrázo- 
lást a belsőre. 


A karakterfolyamoknak , semleges" ( nem léptetett") állapotban kell kezdődniük és vég- 
ződniük. Ez az állapot általában a SzateO. Az unshift(s,to,to end,to next) hívás megnézi az 
s-t és a /to,to end)-be annyi karaktert tesz, amennyire szükség van ahhoz, hogy a karakter- 
sorozatot visszaállítsa a nem léptetett állapotba. Az unshift0 eredménye és a to next fel- 
használási módja az out0 függvényével azonos. 


A length(s from from end, max) azoknak a karaktereknek a számát adja vissza, amelyeket 
az inŐ át tudott alakítani a [from from end)-ből. 


Az encodingO visszatérési értékei a következők lehetnek: 


-1, ha a külső karakterkészlet kódolása állapotot (például léptetett és nem léptetett 
karaktersorozatokat) használ, 

0, ha a kódolás az egyes karakterek ábrázolására különböző számú bájtot használ 
(például egy bájtban egy bitet annak a jelölésére, hogy egy vagy két bájtos-e 
a karakter ábrázolása.), 

n, ha a külső karakterkészlet minden karakterének ábrázolása pontosan 1 bájtos. 


Az always noconwO hívás true-t ad vissza, ha a belső és a külső karakterkészletek között 
nincs szükség átalakításra, különben pedig false-t. Világos, hogy az always noconvO--true 
megnyitja a lehetőséget az adott nyelvi változat számára, hogy a lehető leghatékonyabb 
megvalósítást nyújtsa; azáltal, hogy egyáltalán nem hívja meg az átalakító függvényeket. 


A max lengthO hívás azt a legnagyobb értéket adja vissza, amit a lengthO visszaadhat egy 
adott érvényes paraméterhalmazra. 


A bemenet nagybetűsre alakítása a legegyszerűbb kódátalakítás. Annyira egyszerű, 
amennyire csak egy codecut lehet, mégis ellátja a feladatát: 


class Cut to upper : public codecvtzchar,char, mbstate 121  / nagybetűssé alakítás 
explicit Cut to uppercsize tr - 0) : codecut(r) ( ; 
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brotected: 
// külső ábrázolás olvasása, belső ábrázolás írása: 
result do in(Stateg s, const char" from, const char? from end, const char"£ from next, 
char? to, char?" to end, char:£ to next) const; 


// belső ábrázolás olvasása, külső ábrázolás írása: 


result do out(Statekg s, const char?" from, const char? from end, const char" £ 
Jrom next, 


char? to, char?" to end, char:£ to next) const 
t 


return codecutéchar,char, mbstate t2::do out 
(s rom from end from next to,to end,to next); 


) 
result do unshift(Statek, E" to, E" to end, Ek to next) const f return Ok; ) 


int do encodingO const throw) f return 1; ) 
bool do always noconvO const throu() f return false; ) 


int do length(const Statek, const E" from, const E" from end, size t max) const; 
int do max lengthO const throwO; // a lehetséges legnagyobb lengthO 
5 
codecutéchar,char,mbstate t2::result 
Cut to upper::do in(Stateg s, const char"? from, const char" from end, 
const char" £k from next, char? to, char" to end, char:£ to next) const 


( 


7... SD.6[16] ... 


j 


intmainŐ  — // egyszerű teszt 
( 
locale ulocale(locale0, new Cut to upper); 


cin. imbue(ulocale); 


while (cin:52ch) cout cz ch; 


A codecvut byname változata (§D.4, §D.4.1) is adott: 


template cclass I, class E, class State: 
class std::codecut byname : public codecutAI, E,State: € /£ ... "/ ); 


D. Helyi sajátosságok 1251 


D.4.7. Üzenetek 


Természetesen minden felhasználó a saját anyanyelvét szereti használni, amikor , társalog" 
a programmal, a lokáltól függő üzenetek kifejezésére azonban nem tudunk szabványos el- 
járást biztosítani. A könyvtár csupán egyszerű eszközöket nyújt ahhoz, hogy lokálfüggő ka- 
rakterlánc-halmazokat tárolhassunk, melyekből egyszerű üzeneteket (message) hozhatunk 
létre. A messages osztály alapjában véve egy igen egyszerű, csak olvasható adatbázist ír le: 


class std::messages base (f 
pbublic: 
typedef int catalog; // katalógus-azonosító típus 


J; 


template class Ch: 
class std::messages : public locale::facet, public messages base ( 
bublic: 

typedef Ch char. type; 

typedef basic stringZCh? string type; 


explicit messages(size tr — 09; 


catalog open(const basic string£char:£ fn, const localek ) const; 
string type get(catalog c, int set, int msgid, const string tybek d) const; 
void close(catalog c) const; 


static locale::id id; // facet-azonosító objektum (fD.2, $D.3, SD.3.1 
brotected: 
-messagesO; 


// virtuális "do " függvények a nyilvános függvények számára (lásd §D.4.1) 
j; 


Az open(s loc) hívás megnyitja az s nevű , üzenetkatalógust" a /oc lokálban. A katalógus egy 
megvalósítástól függően elrendezett karakterlánc-halmaz, amelyhez a messages::getŐ) függ- 
vénnyel férhetünk hozzá. Ha az s nevű katalógust nem lehet megnyitni, az obenO negatív 
értéket ad vissza. A katalógust meg kell nyitni a ge első használata előtt. 


A close(cat) hívás bezárja a cat által azonosított katalógust és minden vele kapcsolatos erő- 
forrást felszabadít. 


A get(cat set, id, foo") a (set,id)-vel azonosított üzenetet keresi meg a cat katalógusban. Ha 
megtalálja a karakterláncot, akkor a get ezzel tér vissza; ha nem, az alapértelmezett karak- 
terlánccal (itt ez a 700". 
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Íme egy példa a messages facet-re, ahol az üzenetkatalógus , üzenetek" halmazából álló 
vektor, az ,üzenet" pedig egy karakterlánc: 


struct Set f 
vectorsstring2 msgs; 
, 
struct Cat f 
vectorSSet- sels; 
, 
class My. messages : public messageszchar?; ( 
vectorkCatbk catalogs; 
bublic: 
explicit My messages(size t - 0) : catalogs("new vectorSCat:) f ) 


catalog do open(const string s, const localek loc) const;  // az s katalógus megnyitása 
string do get(catalog c, int s, int m, const stringf ) const; . // az (s,m) üzenet 

// megszerzése c-ből 
void do close(catalog cat) const 


( 


if (catalogs.sizeOOc-cab) catalogs.erase(catalogs.begin OtcaV); 
) 


-My messagesO f delete £catalogs; ) 


A messages minden tagfüggvénye const, így a katalógus adatszerkezete (a vectorcSet:) 
a facet-en kívül tárolódik. 


Az üzeneteket egy katalógus, azon belül egy halmaz, majd a halmazon belül egy üzenet- 
karakterlánc megadásával jelölhetjük ki. Egy karakterláncot paraméterként adunk meg; ezt 
a függvény alapértelmezett visszatérési értékként használja, ha nem találja az üzenetet a 
katalógusban: 


string My messages::do get(catalog cat, int set, int msg, const stringét def) const 
( 

if (catalogs.sizeOc-ca0) return def; 

Catk c - catalogsícatj; 

if (c.sets.sizeOOS-seD return def; 

Set s — c.setslset[; 

if (s.msgs.sizeO-msg) return def; 

return s.msgsímsgl; 
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A katalógus megnyitásakor a lemezről egy szöveges ábrázolást olvasunk egy Cat szerkezet- 
be. Itt olyan ábrázolást választottam, ami könnyen olvasható: a cc£ és 555 jelek egy hal- 
mazt határolnak, az üzenetek pedig szövegsorok: 


messagesáchar:::catalog My messages::do open(const stringít n, const localek loc) const 
( 

string nn - n 4 localeO.nameO; 

ifstream f(nn.c strO); 

if ("p) return -1; 


catalogs push back(CatO); // a katalógus memóriába helyezése 
Caik c — catalogs.backO; 

string s; 

while (fs k.k s--Ize2) f // halmaz olvasása 


c.sets push. back(SetO); 
Setig ss — c.sets.backO; 


while (getline(f5) k.k s 1- "255") ss.msgs. push back(5); // üzenetek beolvasása 
J 


return catalogs.sizeO- 1; 


J 


Íme egy egyszerű felhasználás: 


int mainŐ 


f 
if (has facetz My messages r(localeO)) ( 
cerr Sz "A " cz localeO.nameO cz "Iokálban nincs messages facet.Nn"; 
exit( 1; 
J 
const messageséchar:k m -— use facetz My messages r(IocaleO); 
extern string message directory;  // itt tartom az üzeneteimet 
int cat - m.open(message directory, localeO ); 
if (cat20) f 
cerr 22 "Nincs katalógus Mn"; 
exit( 1; 
j 


cout 2Z m.get(cat, O,O, "Megint téves!") cz endi; 
cout ££ m.get(cat, 1, 2, "Megint téves!") cz endi; 
cout ££ m.get(cat, 1,3, "Megint téves!") c£ endi; 
cout £Z m.get(cat, 3,0, "Megint téves!") c£ endi; 
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Ha a katalógus 


2zZ 
helló 
viszlát 
S55 
2EZ 
igen 
nem 
talán 
S55 


a program a következőt írja ki: 


helló 
talán 
Megint téves! 
Megint téves! 


D.4.7.1. Más facet-ekben lévő üzenetek használata 


Azon túl, hogy a felhasználókkal való kapcsolattartásra alkalmas lokálfüggő karakterlánco- 
kat tárolnak, az üzenetek arra is felhasználhatók, hogy más facet-ek számára tároljanak ka- 
rakterláncokat. A Season io jellemzőt (§D.3.2) például így is megírhattuk volna: 


class Season io : public locale::facet f 


const messageséchar-£ m; // üzenetkönyvtár 
int cat; // üzenetkatalógus 
bublic: 


class Missing messages f );; 


Season io(int i — 0) 
: locale::facet(i), 
m(use facetsSeason messagesr(localeO)), 
cat(m.open(message directory, localeO)) 
€ if (cat20) throw Missing messagesO; ) 


-Season i00 ( ) // lehetővé teszi a Season io objektumok felszámolását (§D.3) 
const stringét to str(Season x) const; // x ábrázolása karakterlánccal 


bool from sti(const string s, Seasonkt x) const; // az s-nek megfelelő 
// Season objektumot x-be helyezi 
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static locale::id id; // facet-azonosító objektum (fD.2, $D.3, SD.3.1 
783 


locale::id Season io::id; // az azonosító objektum meghatározása 


const stringg Season io::to str(Season x) const 


( 
J 


return m--xget(cat, x, "Nincs ilyen évszak"); 


bool Season io::from str(const stringk s, Seasonk x) const 


( 
for (int i - Season::spring; i£-Season::winter; it) 
if (m-cget(cat, i, "Nincs ilyen évszak") -- 5) f 
x — Season(i); 
return true; 


j 


return false; 


J 


Ez az üzenetekre épülő megoldás abban különbözik az eredetitől (SD.3.2), hogy a Season 
karakterláncok halmazát egy adott lokálhoz megíró programozónak a karakterláncokat 
hozzá kell tudnia adni egy messages könyvtárhoz. Ezt az teheti meg könnyen, aki új lokált 
ad a végrehajtási környezethez. Mégis, mivel a messages csak olvasható felületet nyújt, az 
évszakok egy újabb halmazának megadása a rendszerprogramozók hatáskörén kívül esik. 


A messages byname változata (§D.4, §D.4.1) is adott: 


template cclass Ch: 
class std::messages byname : public messageszCh: f / ... "/ 2; 


D.5. Tanácsok 


III  Számítsunk rá, hogy a felhasználókkal közvetlenül társalgó programokat és 
rendszereket több országban is használni fogják. §D.1. 

[2] Ne tételezzük fel, hogy mindenki ugyanazt a karakterkészletet használja, amit 
mi. §D.4.1. 

[3] Ha a bemenet és kimenet függ a helyi sajátosságoktól, lokálokat használjuk és 
ne alkalmi kódot írjunk. §D.1. 

I4] Kerüljük a lokálnevek beágyazását a programszövegbe. §D.2.1. 
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[5] 
[6] 


[7] 
[8] 
[91] 
[10] 
[11] 
[12] 


[13] 


[14] 
[15] 


[16] 
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Használjuk a lehető legkevesebb globális formázást. §D.2.3, 9D.4.4.7. 
Részesítsük előnyben a lokálhoz igazodó karakterlánc-összehasonlításokat és - 
rendezéseket. §D.2.4, §D.4.1. 

A facet-ek legyenek nem módosíthatók. §D.2.2, §D.3. 

Csak kevés helyen változtassuk meg a lokált egy programban. §D.2.3. 

Hagyjuk, hogy a lokál szabályozza a facet-ek élettartamát. §D.3. 

Amikor lokálfüggő [I/O függvényeket írunk, ne felejtsük el kezelni a felhaszná- 
lói (felülír)9) függvények okozta kivételeket. $D.4.2.2. 

A pénzértékek tárolására használjunk egy egyszerű Money típust. §D.4.3. 
Használjunk egyszerű felhasználói típusokat az olyan értékek tárolására, ame- 
lyek lokáltól függő [/O-t igényelnek (és ne a beépített típusok értékeit alakítsuk 
oda-vissza). §D.4.3. 

Ne higgyünk az időértékeknek, amíg nincs valamilyen jó módszerünk arra, 
hogy beleszámítsuk az összes lehetséges módosító tényezőt. §D.4.4.1. 

Legyünk tisztában a time ttípus korlátaival. §D.4.4.1, §D.4.4.5. 

Használjunk olyan dátumbeviteli eljárást, amely többféle formátumot is elfogad. 
§D.4.4.5. 

Részesítsük előnyben az olyan karakterosztályozó függvényeket, amelyekben 

a lokál kifejezetten megadott. §D.4.5, §D.4.5.1. 


D.6. Gyakorlatok 


. (C2,5) Készítsük el a Season io-t (§D.3.2) az amerikai angoltól eltérő nyelvre. 
. (C2) Hozzunk létre egy Season io osztályt (SD.3.2), amelynek konstruktora ne- 


vek halmazát veszi paraméterként, hogy a különböző lokálokban lévő évszakok 
neveit ezen osztály objektumaiként lehessen ábrázolni. 


. (3) Írjunk egy collatezchar?::compare függvényt, amely ábécésorrendet állít 


fel. Lehetőleg olyan nyelvre készítsük el, mint a német, a francia vagy a magyar, 
mert ezek ábécéje az angolnál több betűt tartalmaz. 


. (2) írjunk egy programot, ami logikai értékeket számokként, angol szavakként 


és egy tetszőleges nyelv szavaiként olvas be és ír ki. 


. (C2,5) Határozzuk meg a Time típust a pontos idő ábrázolására. Határozzuk 


meg a Date and time típust is, a Time és valamilyen Date típus felhasználásá- 
val. Fejtsük ki ennek a megközelítésnek a §D.4.4. pontban szereplő Date típus- 
sal szembeni előnyeit és hátrányait. Írjuk meg a Time és a Date and time típu- 
sok lokálfüggő be- és kimeneti eljárásait. 
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6. (2,5) Tervezzünk meg és készítsünk el egy ,postai irányítószám" facetet. Írjuk 
meg legalább két, eltérő címzési szokásokat használó országra. 

7. G2,5) Készítsünk egy , telefonszám" facet-et. Írjuk meg legalább két, eltérő tele- 
fonszám-formát (például (973) 360-8000 és 1223 343000) használó országra. 

8. (2,5) Próbáljuk meg kitalálni, milyen be- és kimeneti formátumokat használ 
C-t4-változatunk a dátumokhoz. 

9. (2,5) Írjunk olyan get timeO függvényt, amely megpróbálja kitalálni a többér- 
telmű dátumok - például a 12/95/1995 — jelentését, de elutasít minden vagy 
majdnem minden hibát. Határozzuk meg pontosan, melyik , találgatást" fogad- 
juk el és gondoljuk át a hibák valószínűségét. 

10. (2) Írjunk olyan get timeO függvényt, ami többfajta bemeneti formátumot fo- 
gad el, mint a §D.4.4.5 pontban szereplő változat. 

11. 02) Készítsünk listát a rendszerünk által támogatott lokálokról. 

12.C2,5) Találjuk meg, rendszerünk hol tárolja a nevesített lokálokat. Ha van hoz- 
záférésünk a rendszer azon részéhez, ahol a lokálok tárolódnak, készítsünk egy 
új, névvel rendelkező /ocale-t. Legyünk óvatosak, nehogy tönkretegyük a már 
létező locale-eket. 

13. 2) Hasonlítsuk össze a Season io két megvalósítását (SD.3.2 és §D.4.7.1. 

14. (2) Írjuk meg, és teszteljük le a Date out facet-et, ami Date-eket ír ki 
a konstruktorának megadott paraméter által meghatározott formában. Fejtsük ki 
ennek a megközelítésnek az előnyeit és hátrányait a date fmt által nyújtott glo- 
bális adatformátummal (§D.4.4.6) szemben. 

15.(2,5) Írjuk meg a római számok (például XIés MDCLID be- és kimeneti 
eljárásait. 

16. C"2,5) Készítsük el és ellenőrizzük a Cvt to upper-t (§D.4.06). 

17.(C2,5) Állapítsuk meg a következők átlagos költségét a clockO függvény felhasz- 
nálásával: (1) függvényhívás, (2) virtuális függvényhívás, (3) egy char beolvasá- 
sa, (4) egy 1 számjegyű int beolvasása, (5) egy 5 számjegyű int beolvasása (6) 
egy 5 számjegyű double, (7) egy 1 karakteres szring, (8) egy 5 karakteres sztring, 
és (9) egy 40 karakteres sziring beolvasása. 

18. C"6,5) Tanuljunk meg egy másik természetes nyelvet. 


Kivételbiztosság a standard könyvtárban 


, Minden úgy működik, ahogy 
elvárjuk — feltéve, hogy 
elvárásaink helyesek." 
(Hyman Rosen) 


Kivételbiztosság s Kivételbiztos eljárások e Erőforrások ábrázolása s Értékadás e 
bush backRO s Konstruktorok és invariánsok e A szabványos tárolók szolgáltatásai " Ele- 
mek beillesztése és eltávolítása e Garanciák és kompromisszumok e swapO s A kezdeti ér- 
tékadás és a bejárók s Hivatkozás elemekre " Predikátumok s Karakterláncok, adatfolya- 
mok, algoritmusok, a valarray és a complex s A C standard könyvtára s Javaslatok 
a könyvtárak felhasználói számára s Tanácsok s Gyakorlatok 


E.1. Bevezetés 


A standard könyvtár függvényei gyakran olyan függvényeket hívnak meg, melyeket a fel- 
használó ad meg akár függvény-, akár sablonparaméterek formájában. Természetesen ezek 
a felhasználói eljárások néha kivételeket váltanak ki. Egyes függvények (például a memó- 
riafoglaló eljárások) önmagukban is képesek kivétel kiváltására: 
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void f(vectorSX-G v, const XG g) 


( 
ul2] - g; // X típus értékadása kivételt válthat ki 
v.push back(g); // vectorZX2 memóriafoglalója kivételt válthat ki 
sort(v.beginO, v.endO); — // X "kisebb mint" operátora kivételt válthat ki 
vectorSX5 u — u; // X másoló konstruktora kivételt válthat ki 
Jéé 


// u itt semmisül meg: biztosítanunk kell, hogy X destruktora helyesen működjön 


Mi történik, ha az értékadás kivételt vált ki, miközben a g értékét próbáljuk lemásolni? A v 
ezután egy érvénytelen elemet fog tartalmazni? Mi történik, ha az a konstruktor, amit 
a vpush backO használ a g lemásolásához, std::bad alloc kivételt vált ki? Megváltozik az 
elemek száma? Bekerülhet érvénytelen elem a tárolóba? Mi történik, ha az X osztály , kisebb, 
mint" operátora eredményez kivételt a rendezés közben? Az elemek ezután részben rende- 
zettekké válnak? Elképzelhető, hogy a rendező eljárás eltávolít egy elemet a tárolóból és 
egy hiba miatt nem teszi vissza? 


A fenti példában szereplő összes kivétel-lehetőség megtalálása az §E.8.[1] feladat célja, ezen 
függeléké az, hogy elmagyarázzuk, hogyan illik viselkednie a fenti programnak az összes 
megfelelően meghatározott X típus esetében (beleértve azt az esetet is, amikor az X kivétele- 
ket válthat ki). Természetesen a függelék nagy részében azt fogjuk tisztázni, mit is nevezünk 
helyes viselkedésnek, illetve megfelelően meghatározottnak a kivételekkel kapcsolatban. 


A függelékben a következőkkel foglalkozunk: 


1. Megvizsgáljuk, hogyan adhat meg a felhasználó olyan típusokat, amelyek meg- 
felelnek a standard könyvtár elvárásainak. 

2. Rögzítjük, milyen garanciákat biztosít a standard könyvtár. 

3. Megnézzük, milyen elvárásokat állít a standard könyvtár a felhasználó által 
megadott programrészekkel szemben. 

4. Bemutatunk néhány hatékony módszert, mellyel kivételbiztos és hatékony táro- 
lókat készíthetünk. 

5. Megemlítjük a kivételbiztos programozás néhány általános szabályát. 


A kivételbiztosság vizsgálata értelemszerűen a legrosszabb esetben tapasztalható viselke- 
déssel foglalkozik. Hol jelentheti egy kivétel a legtöbb problémát? Hogyan tudja a standard 
könyvtár megvédeni magát és a felhasználót a lehetséges problémáktól? Hogyan segíthet 
a felhasználó a problémák elkerülésében? Ne hagyjuk, hogy az itt bemutatott kivétel- 
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kezelési módszerek elfeledtessék velünk, hogy a kivételek kiváltása a legjobb módszer a hi- 
bák jelzésére (414.1, §14.99. Az elveket, a módszereket és a standard könyvtár szolgáltatása- 
it a következő rendszerben tárgyaljuk: 


JE.2. Ebben a pontban a kivételbiztosság fogalmát vizsgáljuk meg. 

SE.3. Itt módszereket mutatunk arra, hogyan írhatunk hatékony, kivételbiztos 
tárolókat és műveleteket. 

SE.4. Ebben a részben körvonalazzuk a standard könyvtár tárolói és műveletei 
által biztosított garanciákat. 

JE.5. Itt összefoglaljuk a kivételbiztosság problémáját a standard könyvtár nem 
tárolókkal foglalkozó részében. 

SE.6. Végül újból áttekintjük a kivételbiztosság kérdését a standard könyvtár 


felhasználóinak szemszögéből. 


Szokás szerint a standard könyvtár példákat mutat azokra a problématípusokra, amelyekre 
egy alkalmazás fejlesztésekor oda kell figyelnünk. A standard könyvtárban a kivételbiztos- 
ság megvalósítására alkalmazott eljárások számos más területen is felhasználhatók. 


E.2. Kivételbiztosság 


Egy objektumon végrehajtott műveletet akkor nevezünk kivételbiztosnak, ha a művelet az 
objektumot akkor is érvényes állapotban hagyja, ha kivétel kiváltásával ért véget. Ez az ér- 
vényes állapot lehet egy hibaállapot is, amit esetleg csak teljes újbóli létrehozással lehet 
megszüntetni, de mindenképpen pontosan meghatározottnak kell lennie, hogy az objek- 
tumhoz logikus hibakezelő eljárást adhassunk meg. A kivételkezelő például törölheti az ob- 
jektumot, kijavíthatja azt, megpróbálkozhat a művelet egy másik változatával vagy megpró- 
bálhat egyszerűen továbbhaladni a hiba figyelmen kívül hagyásával. 


Más szavakkal, az objektum rendelkezni fog egy invariánssal (állapotbiztosító, nem válto- 
zó állapot §24.3.7.1D, melyet konstruktorai állítanak elő, és minden további műveletnek meg 
tartania az általa leírt állapotot, még akkor is, ha kivételek következtek be. A végső rendra- 
kást a destruktorok végzik el. Minden műveletnek figyelnie kell arra, hogy a kivételek ki- 
váltása előtt visszaállítsák az invariánst, hogy az objektum érvényes állapotban lépjen ki 
a műveletből. Természetesen nagy valószínűséggel ez az érvényes állapot nem az az álla- 
pot lesz, amire az alkalmazásnak éppen szüksége lenne. Egy karakterlánc egy kivétel kö- 
vetkeztében például üressé válhat, egy tároló pedig rendezetlen maradhat. Tehát a , kijaví- 
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A e? 


tás" csak azt jelenti, hogy az objektumnak olyan értéket adunk, ami elfogadhatóbb a prog- 
ram számára, mint az, amit a félbeszakadt művelet benne hagyott. A standard könyvtár 
szempontjából a legérdekesebb objektumok a tárolók. 


Az alábbiakban azt vizsgáljuk meg, milyen feltételek mellett nevezhetjük a szabványos tá- 
rolókat feldolgozó műveleteket kivételbiztosnak. Elvileg mindössze két egyszerű megköze- 
lítés közül választhatunk: 


1. , Nincs biztosítás": Ha kivétel lép fel, a művelet által használt valamennyi tárolót 
, valószínűleg sérültnek" tételezzük fel. 

2. ,Erős biztosítás": Ha kivétel lép fel, minden tároló pontosan abba az állapotba ke- 
rül vissza, mint amiben a standard könyvtár műveletének megkezdése előtt volt. 


Sajnos ez a két megoldás annyira egyszerű, hogy igazán nem is alkalmazható. Az első azért 
elfogadhatatlan, mert ha ezen megoldás mellett egy tárolóművelet kivételt vált ki, a tárolót 
többet nem érhetjük el, sőt még nem is törölhetjük anélkül, hogy futási idejű hibáktól kéne 
rettegnünk. A második lehetőség azért nem használható, mert ekkor a visszaállítás megva- 
lósításának költségei a standard könyvtár minden műveletében jelentkeznének. 


A probléma megoldására a Ci standard könyvtára kivételbiztosítási szinteket kínál, me- 
lyek a helyes program készítésének terheit megosztják a standard könyvtár megvalósítói és 
felhasználói között: 


3a Alapbiztosítás az összes műveletre: A standard könyvtár alapvető invariánsai 
mindenképpen fennmaradnak és semmilyen erőforrás (például memóriatarto- 
mány) nem maradhat lefoglalt. 

3b Erős biztosítás a legfontosabb műveletekhez: Az alapbiztosításon túl, a művelet 
vagy sikeresen végrehajtásra kerül, vagy semmilyen változást nem eredményez. 
Ilyen szintű biztosítás csak a könyvtár legfontosabb műveleteit illeti meg, példá- 
ul a push backO,a list osztályban az egyelemű insertO) illetve az 
uninitialized copyO függvényeket (YE.3.1, SE.4.1). 

3c ,Nncs kivétel" biztosítás bizonyos műveletekre Az alapbiztosítás mellett néhány 
művelet egyáltalán nem válthat ki kivételeket. Ez a típusú biztosítás csak né- 
hány egyszerű műveletre valósítható meg, például a swapO vagy a bop backO 
függvényre (VE.4.1). 


Az alapbiztosítás és az erős biztosítás is feltételezi, hogy a felhasználó által megadott műve- 
letek (például az értékadások és a swapO függvények) nem hagyják a tároló elemeit ér- 
vénytelen állapotban és minden általuk lefoglalt erőforrást felszabadítanak. Ezenkívül 
a destruktoroknak nem szabad kivételt kiváltaniuk. Például vizsgáljuk meg az alábbi osztá- 
lyokat (425.79: 
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templatexciass T- class Safe ( 

Tt p; // p egy T típusú, new-val lefoglalt objektumra mutat 
bublic: 

SafeO : p(new D () 

-Safe0 ( delete p; ) 

SafeG operator—(const SafeG a) ( "p - "a.p; return "this; ) 


vag 

]: 

templatexclass T: class Unsafe ( // hanyag és veszélyes kód 
Tt p; // egy T-re mutat 

pbublic: 


Unsafe(T" pp) : P(pp) t ) 
-Unsafe0 ( if (p-2destructibleO) throw EO; delete p; ) 


UnsafeS operator-(const UnsafeG a) 


t 
D-2-TO; // a régi érték törlése (§10.4.11) 
neu(p) Ka.p9; // T létrehozása "p-ben a.p alapján (§10.4.11) 
return "this; 

4 

VES 


J 


void Kvectorz SafecSome type: 2Gug, vectorz UnsafecSome type: 26vb) 
t 

vg.at(1) - SafecSome type:O; 

vb.at(1) - UnsafecSome typer(new Some type); 

TES 
4 


Ebben a példában a Safe osztály létrehozása csak akkor sikeres, ha a 7 osztály is sikeresen 
létrejön. Egy 7 objektum létrehozása meghiúsulhat azért, mert nem sikerül a memóriafog- 
lalás (ilyenkor szd::bad alloc kivétel jelentkezik), vagy azért, mert a 7 konstruktora bármi- 
lyen okból kivételt vált ki. Ettől függetlenül, egy sikeresen létrehozott Safe esetében a b egy 
hibátlan 7 objektumra mutat, míg ha a konstruktor sikertelen, sem 7; sem Safe objektum 
nem jön létre. Ugyanígy kivételt válthat ki a Tértékadó művelete is; ekkor a Safe értékadó 
művelete (a Ct4 működésének megfelelően) továbbdobja a kivételt. Mindez nem jelent 
problémát mindaddig, amíg a Tértékadó operátora saját operandusát megfelelő állapotban 
hagyja. Tehát a Safe követelményeinknek megfelelően működik, így a standard könyvtár 
műveletei Safe objektumokra alkalmazva logikus és megfelelően meghatározott eredményt 
fognak adni. 
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Ezzel szemben az UnsafeO konstruktort figyelmetlenül írtuk meg (pontosabban figyelme- 
sen úgy írtuk meg, hogy a helytelen formát bemutassa). Egy Unsafe objektum létrehozása 
sohasem fog meghiúsulni. Ehelyett az objektumot használó műveletekre (például az érték- 
adásra és a megsemmisítésre) bízzuk, hogy törődjenek saját belátásuk szerint az összes le- 
hetséges problémával. Az értékadás meghiúsulhat úgy, hogy a Tmásoló konstruktora kivált 
egy kivételt. Ilyenkor a Ttípusú objektumot nem meghatározott állapotban hagyjuk, hiszen 
a "p régi értékét töröltük, de nem helyettesítettük érvényes értékkel. Az ilyen működés kö- 
vetkezményei általában megjósolhatatlanok. Az Unsafe destruktora tartalmaz egy remény- 
telen próbálkozást az érvénytelen megsemmisítés elkerülésére, egy kivétel meghívása egy 
másik kivétel kezelése közben azonban a terminate0 (§14.7) meghívását eredményezi, míg 
a standard könyvtár elvárja, hogy a destruktor szabályosan visszatérjen az objektum törlése 
után. A standard könyvtár nem készült fel és nem is tud felkészülni arra, hogy garanciákat 
adjon olyan felhasználói objektumokra, melyek nem megfelelően működnek. A kivételke- 
zelés szempontjából a Safe és az Unsafe abban különbözik, hogy a Safe a konstruktort hasz- 
nálja az invariáns (424.3.7.1) létrehozásához, ami lehetővé teszi, hogy műveleteit egyszerű- 
en és biztonságosan valósítsuk meg. Ha az állapotbiztosító feltétel nem elégíthető ki, 
kivételt kapunk, mielőtt még az érvénytelen objektum létrejönne. Ugyanakkor az Unsafe 
nem rendelkezik értelmes invariánssal és a különálló műveletek mindenféle kivételeket vál- 
tanak ki, anélkül, hogy egy , központi" hibakezelő eljárás rendelkezésükre állna. Természe- 
tesen ez gyakran vezet a standard könyvtár (ésszerű) feltételezéseinek megsértéséhez. Az 
Unsafe esetében például érvénytelen elemek maradhatnak egy tárolóban, miután 
a T::operator—-0 egy kivételt váltott ki, és a destruktor is eredményezhet kivételeket. 

A standard könyvtár biztosításainak viszonya a rossz viselkedésű felhasználói műveletek- 
hez ugyanolyan, mint a nyelv biztosításainak viszonya a típusrendszer szabályait megsértő 
műveletekhez. Ha egy alapműveletet nem meghatározott szabályai szerint használunk, az 
eredmény nem meghatározható lesz. Ha egy vector elemeinek destruktora kivételt vált ki, 
ugyanúgy nincs jogunk logikus viselkedést elvárni, mint amikor egy kezdőértékként 
véletlenszámmal feltöltött mutatóval szeretnénk adatokat elérni: 


class Bomb ( 
bublic: 

PARS 

-BombO ( throw TroubleO; ) 
J; 


vectorSBomb: b(109; // nem meghatározható viselkedéshez vezet 


void JO 

t 
int" p - reinterpret casizint"(randO); // nem meghatározható viselkedéshez vezet 
p-7 

) 
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De nézzük a dolgok jó oldalát: ha betartjuk a nyelv és a standard könyvtár alapvető szabá- 
lyait, a könyvtár jól fog viselkedni úgy is, ha kivételeket váltunk ki. 


Amellett, hogy rendelkezésünkre áll a tiszta kivételbiztosság, szeretjük elkerülni az erőfor- 
rásokban előforduló , lyukakat"; azaz egy olyan műveletnek, amely kivételt vált ki, nem elég 
az operandusait meghatározott állapotban hagynia, biztosítania kell azt is, hogy minden 
igényelt erőforrás valamikor felszabaduljon. Egy kivétel kiváltásának helyén például min- 
den korábban lefoglalt memóriaterületet fel kell szabadítanunk vagy azokat valamilyen ob- 
jektumhoz kell kötnünk, hogy később a memória szabályosan felszabadítható legyen. 


A standard könyvtár biztosítja, hogy nem lesznek erőforrás-lyukak, ha azok a felhasználói 
műveletek, melyeket a könyvtár használ, maguk sem hoznak létre ilyeneket: 


void leak(bool abort) 

t 
vectorcint: v(109; // nincs memória-elszivárgás 
vectorsint2?" p - new vectorsint2(10); // memória-elszivárgás lehetséges 


auto pirz vectorsint: - g(new vectorsint:(10)9; // nincs memória-elszivárgás (§14.4.2) 


if (abort) throw UDpO; 
PB 
delete p; 


Ha kivétel következik be, a v vector és a g által mutatott vector helyesen lesz törölve, így 
minden általuk lefoglalt erőforrás felszabadul. Ezzel szemben a 5 által mutatott veczor ob- 
jektumot nem védjük a kivételektől, így az nem fog törlődni. Ha a kódrészletet biztonságos- 
sá akarjuk tenni, vagy magunknak kell felszabadítani a D által mutatott területet a kivétel ki- 
váltása előtt, vagy biztosítanunk kell, hogy valamilyen objektum — például egy auto ptr 
(§14.4.2) — birtokolja azt és szabályosan felszabadítsa akkor is, ha kivétel következett be. 


Figyeljük meg, hogy a nyelv szabályai a részleges létrehozással, illetve megsemmisítéssel 
kapcsolatban biztosítják, hogy a részobjektumok és az adattagok létrehozásakor bekövetke- 
ző kivételeket a standard könyvtár eljárásai minden külön erőfeszítés nélkül helyesen kezel- 
jék (§14.4.19. Ez minden kivételekkel kapcsolatos eljárás esetében nagyon fontos alapelv. 


Gondoljunk arra is, hogy nem a memória az egyetlen olyan erőforrás, amelyben lyukak for- 
dulhatnak elő. A megnyitott fájlok, zárolások, hálózati kapcsolatok és a szálak is olyan 
rendszererőforrások, melyeket egy függvénynek fel kell szabadítania vagy át kell adnia va- 
lamely objektumnak egy kivétel kiváltása előtt. 


1266 Függelékek és tárgymutató 


E.3. A kivételbiztosságot megvalósító eljárások 


A standard könyvtár — szokás szerint — bemutatja azokat a problémákat, amelyek sok más 
helyzetben is előfordulhatnak és ezekre olyan megoldást ad, ami széles körben felhasznál- 
ható. A kivételbiztos programok írásának alapvető eszközei a következők: 


1. A try blokk (§8.3.1 
2. A , kezdeti értékadás az erőforrás megszerzésével" eljárás (414.4) 


A követendő általános elvek: 


3. Soha ne , dobjunk ki" adatokat úgy, hogy nem tudjuk pontosan, mi kerül 
a helyükre. 
4. Az objektumokat mindig érvényes állapotban hagyjuk, amikor kivételt váltunk ki. 


Ha betartjuk ezeket a szabályokat, minden hibát megfelelően kezelhetünk. Ezen elvek kö- 
vetése a gyakorlatban azért jelent problémát, mert még a legártalmatlanabbnak tűnő eljárá- 
sok (például a c, az — vagy a sortO) is kiválthatnak kivételeket. Annak megállapításához, 


hogy egy programban mit kell megvizsgálnunk, nagy tapasztalatra van szükség. 


Ha könyvtárat írunk, célszerű az erős kivételbiztosságot (V4E.2) célul kitűznünk és minden- 
hol meg kell valósítanunk az alapbiztosítást. Programok írásakor a kivételbiztosság kevés- 
bé fontos szempont. Például, amikor egy egyszerű adatfeldolgozó programot készítünk sa- 
ját magunknak, általában nem baj, ha a program egyszerűen befejeződik, amikor a virtuális 
memória valamilyen hiba miatt elfogy. Ugyanakkor a helyesség és az alapvető kivételbiz- 
tosság szorosan kapcsolódik egymáshoz. 


Az alapvető kivételbiztosság megvalósítására szolgáló eljárások — például az állapotbiztosí- 
tók megadása és fenntartása (424.3.7.1) — nagyon hasonlítanak azokhoz, melyek segítségé- 
vel kicsi és helyesen működő programokat hozhatunk létre. Ebből következik, hogy az 
alapvető kivételbiztosság (az alapbiztosítás; SE.2) — vagy akár az erős biztosítás — megvaló- 
sítása csupán jelentéktelen teljesítnényromlással jár. Lásd: §E.8[171] 


Az alábbiakban a vector szabványos tároló (416.3) egy megvalósítását adjuk meg, hogy be- 
mutassuk, milyen feladatokat kell megoldanunk az ideális kivételbiztosság megvalósításá- 
hoz és hol érdemes alaposabb felügyeletet biztosítanunk. 


E. Kivételbiztosság a standard könyvtárban 1267 


E.3.1. Egy egyszerű vektor 
A vector (§16.3) leggyakoribb megvalósításában három mutató (vagy az ezzel egyenértékű 


mutató-eltolás pár) szerepel: egy az első elemre, egy az utolsó utáni elemre és egy az utol- 
só utáni lefoglalt helyre hivatkozik (§17.1.39: 


Jirst 


space 
18 Mlle ESRE 


Vector: 

















Lássuk, mire van szükségünk a vector deklarációjában, ha csak a kivételbiztosság és az erő- 
forrás-lyukak elkerülése szempontjából vizsgáljuk az osztályt: 


templatecxciass T, class A - allocatorsT: 2 
class vector ( 


Private: 
Tt u; // a lefoglalt terület eleje 
T" space; // az elemsorozat vége, bővítés számára tartalékolt terület kezdete 
T" last; // a lefoglalt terület vége 
A alloc; // memóriafoglaló 
public: 
explicit vector(size type n, const TE val - TO, const AG - AOJ; 
vector(const vector§ a); // másoló konstruktor 
vector6 operator-(const vector6 a); // másoló értékadás 
—vectorO; 


size type sizeO const ( return space-u; ) 
size type capacityO const ( return last-v; ) 


void push back(const TEJ; 
VAN 
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Vizsgáljunk először egy meggondolatlan konstruktor-megvalósítást: 


templatecciass T; class Az 
vectorST,A2::vectorcsize type n, const IG val, const AG a) // vigyázat: naív megvalósítás 
: alloc(a) // memóriafoglaló másolása 
( 
v — alloc.allocate(n); // memória lefoglalása az elemek számára (§19.4.1) 
space - last — van; 
Jor(1"p - v; p/-last; 43p) a.construct(b,vaD;  // val létrehozó másolása "p-be (§19.4.1 
] 


Itt három helyen keletkezhet kivétel: 


1. Az allocate0 függvény kivételt válthat ki, ha nincs elegendő memória. 

2. A memóriafoglaló (allokátor) másoló konstruktora is eredményezhet kivételt. 

3. A Telemtípus másoló konstruktora is kiválthat kivételt, ha nem tudja lemásolni 
a val értéket. 


Egyik esetben sem jön létre új objektum, tehát a vector konstruktora sem fut le (414.4.1). 


Ha az allocate0 végrehajtása sikertelen, a throw már akkor kilép a konstruktorból, amikor 
még semmilyen erőforrást nem foglaltunk le, így ezzel minden rendben. 


Ha a Tmásoló konstruktora eredményez hibát, már lefoglaltunk valamennyi memóriát, így 
azt fel kell szabadítanunk, ha el akarjuk kerülni a memória-elszivárgást. Az igazán nagy 
problémát az jelenti, hogy a 7 másoló konstruktora esetleg akkor vált ki kivételt, amikor 
már néhány objektumot sikeresen létrehozott, de még nem az összeset. 


Ezen probléma kezeléséhez nyilván kell tartanunk, hogy eddig mely elemeket hoztuk lét- 
re, és amikor hiba következik be, ezeket (és csak ezeket) törölnünk kell: 


templatecciass T; class Az 
vectorcT,A:::vectorcsize type n, const TG val, const AG a) // jól kidolgozott megvalósítás 


: alloc(a) // memóriafoglaló másolása 

v -— alloc.allocate(n); // memória lefoglalása az elemek számára 
iterator p; 
try ( 


iterator end — vin; 
for (p-v; p!-end; 44p) alloc.construct(b,val; — // elemek létrehozása (§19.4.1) 
last - space - p; 

4 
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catch C(...) ( 
for (iterator g - v; g!-b; 449) alloc.destroy(g);  /7 létrehozott elemek megsemmisítése 
alloc.deallocate(v,n); // memória felszabadítása 
throw; // továbbdobás 

4 


J 


A pluszköltség ez esetben is csak a try blokk költsége. Egy jó Ct-4-változatban ez elhanya- 
golható a memóriafoglaláshoz és az elemek kezdeti értékadásához képest. Ahol a try blokk 
költsége magas, esetleg beilleszthetjük az if(n) vizsgálatot a try elé, ezzel az üres vektort kü- 
lön esetként kezelhetjük. 


A konstruktor nagy részét az uninitialized fill0 függvény kivételbiztos megvalósítása tölti ki: 


templatecxciass For, class T- 
void uninitialized fill(For beg, For end, const IG x) 


t 
For p; 
try ( 
for (p-beg; p/!-end; 44p) 
new(static castzvoid"(6"p)) K(x); // x létrehozó másolása "p-ben (§10.4.11) 
) 
catch (...) ( // a létrehozott elemek törlése és továbbdobás: 
for (For ag - beg; g/-p; 119) (67p-2-TŐ; //(§10.4.11 
throw; 
) 
) 


A furcsa 6 kifejezésre azért volt szükség, hogy a nem mutató bejárókat (iterátorokat) is 
kezelhessük. Ilyenkor ahhoz, hogy mutatót kapjunk, a hivatkozással meghatározott elem 
címét kell vennünk. A void" átalakítás biztosítja, hogy a standard könyvtár elhelyező függ- 
vényét használjuk (419.4.59, nem a felhasználó által a 7"típusra megadott operator newO 
függvényt. Ez az eljárás olyan alacsony szinten működik, ahol a teljes általánosságot már 
elég nehéz biztosítani. 


Szerencsére nem kell újraírnunk az uninitialized fill0 függvényt, mert a standard könyv- 
tár biztosítja hozzá a megkívánt erős biztosítást (VE.2). Gyakran elengedhetetlen , hogy 
olyan kezdőérték-adó művelet álljon rendelkezésünkre, amely vagy minden elemet hibát- 
lanul tölt fel kezdőértékkel, vagy — hiba esetén — egyáltalán nem ad vissza elemeket. Éppen 
ezért a standard könyvtárban szereplő uninitialized fill0, uninitialized fill nO és 
uninitialized copyO függvény (§19.4.4) biztosítja ezt az erős kivételbiztosságot (VE.4.4). 
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Figyeljük meg, hogy az uninitialized fill0 nem védekezik az elemek destruktora vagy 
a bejáróműveletek által kiváltott kivételek ellen (VE.4.4), ez ugyanis elviselhetetlenül nagy 
költséget jelentene (lásd §E.8[16-17D. 


Az uninitialized fill0 nagyon sokféle sorozatra alkalmazható, ezért csak előre haladó be- 
járókat vesz át (419.2.1), amivel viszont nem tudja garantálni, hogy az elemeket létrehozá- 
sukkal fordított sorrendben törli. 


Az uninitialized fill0 felhasználásával az alábbiakat írhatjuk: 


templatecxcliass T, class Az 


vectorcST,A2::vectorcsize type n, const TE val, const AG a) // zavaros megvalósítás 
:alloc(a) // memóriafoglaló másolása 
t 
v - alloc.allocate(n); // memória lefoglalása az elemek számára 
try ( 
uninitialized fillív,vtn,vaD; // elemek másolása 
space - last — van; 
] 
catch (...) ( 
alloc.deallocate(v,n); // memória felszabadítása 
throw; // továbbdobás 
] 


Ennek ellenére ezt a programot nem nevezhetjük szépnek. A következőkben bemutatjuk, 
hogyan tehetjük a programot sokkal egyszerűbbé. 


Figyeljük meg, hogy a konstruktor újra kiváltja azt a kivételt, amit elkapott. A cél az, hogy 
a vector osztályt , átlátszóvá" tegyük a kivételek előtt, mert így a felhasználó pontosan meg- 
állapíthatja a hiba okát. A standard könyvtár összes tárolója rendelkezik ezzel a tulajdon- 
sággal. A kivételekkel szembeni átlátszóság gyakran a legjobb lehetőség a sablonok és a ha- 
sonló ,vékony" rétegek számára. Ez ellentétben áll a programrendszerek nagyobb 
részeinek ( moduljainak") irányvonalával, hiszen ezeknek általában önállóan kell kezelni- 
ük minden hibát. Pontosabban, az ilyen modulok készítőinek fel kell tudniuk sorolni az 
összes kivételt, amit a modul kiválthat. Ennek megvalósításához vagy a kivételek csoporto- 
sítására (414.2), vagy az alacsonyszintű eljárások és a modul saját kivételeinek összekapcso- 
lására (§14.6.3), esetleg a kivételek meghatározására (§14.6) van szükség. 
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E.3.2. A memória ábrázolása 


A tapasztalatok bebizonyították, hogy helyes, kivételbiztos programok készítése try blokkok 
segítségével bonyolultabb annál, mint amit egy átlagos programozó még elfogad. Valójában 
feleslegesen bonyolult, hiszen van egy másik lehetőség: a , kezdeti értékadás az erőforrás 
megszerzésével" (414.4), melynek segítségével csökkenthetjük azon programsorok számát, 
melyek egy , stílusos" program megvalósításához szükségesek. Esetünkben a legfontosabb 
erőforrás, amire a vector osztálynak szüksége van, egyértelműen a memória, melyben az 
elemeket tároljuk. Ha bevezetünk egy segédosztályt, amely a vector által használt memóri- 
át ábrázolja, leegyszerűsíthetjük programunkat és csökkenthetjük annak esélyét, hogy vé- 
letlenül elfelejtjük felszabadítani a memóriát. 


templatecxciass T, class A - allocatorsT: 2 
struct vector. base ( 


A alloc; // memóriafoglaló 

Tt u; // a lefoglalt terület eleje 

T" space; // az elemsorozat vége, bővítés számára tartalékolt terület kezdete 
T" last; // a lefoglalt terület vége 


vector. base(const AG a, typename A::size type n) 
: allocCa), v(a.allocate(n)), space(vxn), last(van) ( ) 
-vector baseO t alloc.deallocate(v, last-v); ) 


Amíg a v és a last mutató helyes, a vector. base objektum megsemmisíthető. A vector. base 
osztály a Ttípus számára lefoglalt memóriát kezeli és nem 7Ttípusú objektumokat, ezért mi- 
előtt egy vector. base objektumot törlünk, minden ennek segítségével létrehozott objektu- 
mot is törölnünk kell. 


Természetesen magát a vector. base osztályt is úgy kell megírni, hogy ha kivétel következik 


be (a memóriafoglaló másoló konstruktorában vagy az allocate0 függvényben), ne jöjjön 
létre vector. base objektum, így memória-elszivárgás sem következik be. 


A vector. base felhasználásával a vector osztályt a következőképpen határozhatjuk meg: 


templatecxciass T, class A - allocatorST: 2 
class vector : private vector. basezT, A: ( 

void destroy elements$0 tf for (I"p - v; p!-space; 44p) p-2-TO; ) / §10.4.11 
public: 

explicit vector(size type n, const TE val - TO, const AG - AO9; 
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vector(const vector§ a); // másoló konstruktor 
vector6 operator—-(const vectorG a); // másoló értékadás 


-vector) ( destroy elementsO; ) 


size type sizeO const ( return sbace-u; ) 
size type capacityO const f return last-v; ) 


void push back(const TEJ; 
SANTA 


A vector destruktora az összes elemre egymás után meghívja a 7 típus destruktorát. Ebből 
következik, hogy ha egy elem destruktora kivételt vált ki, a vector destruktora sem tud hi- 
bátlanul lefutni. Ez igen nagy problémát okoz, ha egy másik kivétel miatt kezdeményezett 
, verem-visszatekerés" közben következik be, hiszen ekkor a terminate0 függvény fut le 
(§14.79. Ha a destruktor kivételt vált ki, általában erőforrás-lyukak keletkeznek és azok az 
eljárások, melyeket szabályos viselkedésű objektumokhoz fejlesztettek ki, megjósolhatatla- 
nul fognak működni. Nem igazán van használható megoldás a destruktorokban keletkező 
kivételek kezelésére, ezért a könyvtár semmilyen biztosítást nem vállal, ha az elemek ilyen 
viselkedésűek lehetnek (§E.4). 


A konstruktort az alábbi egyszerű formában adhatjuk meg: 


templatexcliass T, class Az 
vectorST,A2::vectorcsize type n, const TG val, const AG a) 

: vector. basezT, A2(a n) // terület lefoglalása n elem számára 
t 

uninitialized fillrv,van,vaD; // elemek másolása 


] 


A másoló konstruktor mindössze abban különbözik ettől, hogy az uninitialized fill0 he- 
lyett az uninitialized copyO függvényt használja: 


templatecciass T; class Az 
vectorST,A:::vector(const vectorST,A26 a) 

: vector. basezT,A:(a.alloc,a.sizeO ) 
t 

uninitialized copy(a.beginO,a.endO,v); 
) 
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Figyeljük meg, hogy az ilyen stílusú konstruktor kihasználja a nyelvnek azon alapszabályát, 
hogy ha a konstruktorban kivétel keletkezik, azokra a részobjektumokra (és alapobjektu- 
mokra), melyek sikeresen létrejöttek, a destruktor is szabályosan lefut (§14.4.1). Az 
uninitialized fillő és testvérei (§E.4.4) ugyanilyen szolgáltatást nyújtanak a félig létrehozott 
sorozatok esetében. 


E.3.3. Értékadás 


Szokás szerint az értékadás abban különbözik a létrehozástól, hogy a korábbi értékekre is 
figyelnünk kell. Vizsgáljuk meg az alábbi megvalósítást: 


templatecciass T; class Az 
vectorST,A2G vectorST, A2::operator-(const vectlorg a) — // erős biztosítást ad (§E.2) 
( 
vector. basezT, A: b(alloc,a.sizeO ); // memória lefoglalása 
uninitialized copy(a.beginO,a.endO,b.v); — // elemek másolása 
destroy elementsO; 


alloc.deallocate(v, last-v); // a régi memóriaterület felszabadítása 
vector. base::operator—(b); // ábrázolás elhelyezése 

b.v — 0; // felszabadítás megelőzése 

return "this; 


Ez az értékadás szép és kivételbiztos is, de túl sok mindent ismétel meg a konstruktorból és 
a destruktorból. Ennek elkerülésére a következő eljárást írhatjuk: 


templatecxciass T; class Az 
vectorST,A2G vectorST, A:::operator—(const vectorg a) — // erős biztosítást ad (§E.2) 


t 
vector temp(a); // "a" másolása 
swapg vector. basezT, Az -( this, temp); // ábrázolások felcserélése 
return "this; 

4 


A régi elemeket a temp destruktora törli, az általuk lefoglalt területet pedig a temp változó 
vector. base objektumának destruktora szabadítja fel. 


A két változat teljesítménye szinte teljesen egyenlő. Valójában csak két különböző formában 
adjuk meg ugyanazokat a műveleteket. A második megvalósítás viszont rövidebb és nem is- 
métli a vector osztály egyéb függvényeiben már szereplő kódrészleteket, így az értékadás 
ezen változata kevesebb hibalehetőséget tartalmaz és egyszerűbb rendben tartani is. 
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Figyeljük meg, hogy az önértékadás szokásos vizsgálata hiányzik az eljárásból (410.4.49: 
if (this -—- 6a) return "this; 


Ezek az értékadó műveletek először létrehoznak egy másolatot, majd lecserélik az eleme- 
ket. Ez a megoldás automatikusan kezeli az önértékadás problémáját. Úgy döntöttem, hogy 
a ritkán előforduló önértékadás külön vizsgálata nem jár annyi haszonnal, hogy érdemes le- 
gyen ezzel lassítani az általános esetet, amikor egy másik vector objektumot adunk értékül. 


Mindkét esetben két, esetleg jelentős optimalizálási lehetőség hiányzik: 
1. Ha az értéket kapó vektor mérete elég nagy ahhoz, hogy az értékül adott vek- 
tort tárolja, nincs szükség új memória lefoglalására. 


2. Az elemek közötti értékadás hatékonyabb lehet, mint egy elem törlése, majd 
külön létrehozása. 


Ha ezeket a javításokat is beépítjük, a következő eredményt kapjuk: 


templatecciass T; class Az 
vectorST,A2G6 vectorST, A:::operator-(const vectorG a) // optimalizált, alapbiztosítás (§E.2) 


( 
if (capacityO c a.sizeO) ( // új vektorábrázolás számára terület lefoglalása 
vector temp(a); // "a" másolása 
swapxg vector. baseZT, A2 2(Cthis,temp); // az ábrázolások felcserélése 
return "this; 
J 
if (this -- Ga) return "this; // védelem az önértékadás ellen (§10.4.4) 


// a régi elemek értékadása 

size type sz — sizeO; 
size type asz — a.sizeO; 
alloc - a.get allocatorO; // memóriafoglaló másolása 
if (aszzs-sz) f 

copy(a.beginO, a.beginOtasz, v); 

for (T"p - vrasz; p!-space; t4p) p-2-TO; // felesleges elemek felszámolása (§10.4.11) 
) 
else ( 

copy(a.beginO, a.beginO-tsz, VI); 

uninitialized copy(a.beginO-tsz,a.endO,space); — // további elemek létrehozása 
) 
space - vtasz; 
return "this; 
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Ezek az optimalizációk nem valósíthatók meg büntetlenül. A copyO eljárás nem nyújt erős 
kivételbiztosítást, mert nem garantálja, hogy a cél változatlan marad, ha másolás közben ki- 
vétel következik be. Tehát ha a 7::operator-O kivételt vált ki a copyO művelet közben, elő- 
fordulhat, hogy az értéket kapó vektor megváltozik, de nem lesz az értékül adott vektor 
pontos másolata. Lehetséges például, hogy az első öt elemet sikerül lemásolni az értékül 
adott vektorból, de a többi változatlan marad, sőt akár az is elképzelhető, hogy egy elem 
(az, amelyiket éppen másoltuk, amikor a 7T::oberator-0 kivételt váltott ki) olyan értéket fog 
tartalmazni, amely nem egyezik meg sem az eredetivel, sem a másolandóval. Azt azért el- 
mondhatjuk, hogy ha a 7::oberator-0 érvényes állapotban hagyja operandusát egy kivétel 
kiváltásakor is, a teljes vector is érvényes állapotban marad, bár nem abban az állapotban, 
amit szerettünk volna. 


A fentiekben a memóriafoglalót is értékadással másoltuk le. Valójában a memóriafoglalók- 
tól nem mindig követeljük meg, hogy rendelkezzenek értékadással (419.4.3, lásd 
még:§E.8I9D. 


A standard könyvtár vector értékadásának legutóbbi megvalósítása gyengébb kivételbiztos- 
ságot, de nagyobb hatékonyságot biztosít. Csak az alapbiztosítást nyújtja, ami megfelel 
a legtöbb programozó kivételbiztosságról alkotott fogalmának, de nem áll rendelkezésünk- 
re erős biztosítás (VE.2). Ha olyan értékadásra van szükségünk, amely kivétel felléptekor 
a vector-t változatlanul hagyja, olyan könyvtár-megvalósítást kell használnunk, amely erős 
biztosítást nyújt az ilyen helyzetekben is vagy saját magunknak kell megírni az értékadó 
műveletet: 


templatecciass T; class Az 
void safe assign(vectorST,A2€6 a, const vectorST,A26 b) // "magától értendő" a - b 
t 

vectorcT, A: temp(a.get allocatorO); 

temp.reserve(b.sizeO ); 

for (typename vectorST, Az::iterator p - b.beginO; p!-b.endO; 44p) 

temp.push backCp); 
swap(a temp); 


Ha nincs elegendő memória ahhoz, hogy létrehozzuk a temp változót b.sizeO elem számá- 
ra, az std:bad alloc kivételt váltjuk ki, mielőtt bármilyen változtatást végeznénk az a vekto- 
ron. Ehhez hasonlóan, ha a push backO végrehajtása nem sikerül, az a akkor is érintetlen 
marad, hiszen minden push backO műveletet a temp objektumon hajtunk végre az a he- 
lyett. Ezzel a megoldással azt is biztosítjuk, hogy felszabaduljon a temp minden eleme, amit 
a push bacRO segítségével létrehoztunk, mielőtt a hibát okozó kivételt újra kiváltanánk. 
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A swapO nem másolja a vektorok elemeit, csupán lecseréli a vector adattagjait, így 
a vector. base objektumot is. Ennek következtében a swapO akkor sem válthat ki kivételt, 
ha az elemek műveletei képesek erre (VE.4.3). A safe assignO nem készít felesleges máso- 
latokat az elemekről, tehát elég hatékony tud lenni. 


Szokás szerint vannak más lehetőségek is a nyilvánvaló megvalósítás mellett, például rábíz- 
hatjuk magára a könyvtárra, hogy az elemeket az ideiglenes vektorba másolja: 


templatexciass T, class Az 

void safe assign(vectorST;A26 a, const vectorST, 426 b) // egyszerű a - b 

( 
vectorST, A: temp(b); // b elemeinek másolása az ideiglenes változóba 
swap(a, temp); 

J 


Sőt, egyszerű érték szerinti paraméterátadást (47.2) is használhatunk: 


templatexciass T; class Az 
void safe assign(vectorST;A:G a, vectorzT;4A: b) // egyszerű a - b 
// (figyelem: b érték szerint átadva) 
( 
swap(Ca, b); 
J 


A safe assignO ez utóbbi két változata a vector memóriafoglalóját nem másolja le, ami meg- 
engedett optimalizáció (lásd §19.4.39. 


E.3.4. A push back() 


A kivételbiztosság szemszögéből nézve a bush backO nagyon hasonlít az értékadásra ab- 
ban, hogy nem szabad a vector objektumot megváltoztatnunk, ha az új elem beillesztése va- 
lamilyen problémába ütközik: 


templatex class T, class Az 
void vectorZT, A2::push back(const TE x) 
t 
if (space -- lasD(  / nincs több hely; áthelyezés 
vector. base b(alloc,sizeO?2"sizeO:29; // a lefoglalás megkettozése 
uninitialized copy(v,space, b.v); 
neu(b.space) K(x); // x másolatának "b.space-be helyezése (§10.4.11) 
44b.space; 
destroy elementsO; 
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swapgvector. basezT, A2 (b, this); // az ábrázolások felcserélése 

return; 
) 
new(space) IX); // x másolatának "space-be helyezése (§10.4.11) 
trspace; 


J 


Természetesen, a "space kezdeti értékadására szolgáló másoló konstruktor válthat ki kivé- 
telt. Ha ez történik, a vector változatlan marad és a space értékét sem növeljük meg. Ilyen- 
kor a vektor elemeit sem kell áthelyeznünk a memóriában, tehát az eddigi bejárók is ér- 
vényben maradnak. Így ez a megvalósítás erős biztosítást ad: ha egy memóriafoglaló vagy 
egy felhasználói eljárás kivételt vált ki, a vector nem változik meg. A standard könyvtár ilyen 
biztosítást nyújt a bush backO függvényhez (VE.4.1. 


Figyeljük meg, hogy az eljárásban nincs egyetlen try blokk sem (attól eltekintve, ami az 
uninitialized copyO függvényben, rejtve szerepeD. A módosítást a műveletek sorrendjé- 
nek pontos megválasztásával hajtjuk végre, így ha kivétel keletkezik, a vektor értéke nem 
változik meg. 


Ez a megközelítés — miszerint az utasítások sorrendje adja a kivételbiztosságot — és a , kez- 
deti értékadás az erőforrás megszerzésével" (414.4) alkalmazása elegánsabb és hatéko- 
nyabb megoldást kínál, mint a hibák kifejezett kezelése try blokkok segítségével. Ha utasí- 
tásainkat szerencsétlen sorrendben írjuk le, sokkal több kivételbiztossági problémával kell 
megküzdenünk, mint a kivételkezelő eljárások elhagyása mellett. A sorrend meghatározá- 
sakor az alapszabály az, hogy ne semmisítsünk meg információt, mielőtt az azt helyettesítő 
adatokat létre nem hoztuk és nem biztosítottuk, hogy azokat kivételek veszélye nélkül átír- 
hassuk a helyükre. 


A kivételkezelés egyik következménye, hogy a program végrehajtása során a vezérlés meg- 
lepő helyekre kerülhet. Az olyan egyszerű, helyi vezérléssel rendelkező függvényekben, 
mint az operator—-(), a safe assignO vagy a bush backO, meglepetések ritkábban fordulnak 
elő. Ha ránézünk egy kódrészletre, viszonylag egyszerűen megállapíthatjuk, hogy egy adott 
sor válthat-e ki kivételt és mi lesz annak következménye. A nagyobb függvényekben, me- 
lyekben bonyolult vezérlési szerkezeteket (például bonyolult feltételes utasításokat és egy- 
másba ágyazott ciklusokaD) használunk, az ilyen kérdésekre nehéz választ adni. A try blok- 
kok alkalmazása a helyi vezérlést még tovább bonyolítja, így újabb keveredéseket és 
hibákat eredményezhet (414.4). Azt hiszem, az utasításrendezés és a , kezdeti értékadás az 
erőforrás megszerzésével" hatékonysága a nagyobb méretű try blokkokkal szemben éppen 
a helyi vezérlés egyszerűsítésében rejlik. Egyszerűbben fogalmazva, a , stílusos" programo- 
kat egyszerűbb megérteni és egyszerűbb helyesen megírni. 
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Gondoljunk rá, hogy az itt szereplő vector csak a kivételek által okozott problémák és az 
ezen problémák megoldására kidolgozott eljárások bemutatására szolgál. A szabvány nem 
követeli meg, hogy minden megvalósítás pontosan úgy nézzen ki, ahogy itt bemutatjuk. 
A szabvány által biztosított garanciákat az §E.4. pontban tárgyaljuk. 


E.3.5. Konstruktorok és invariánsok 


A kivételbiztosság szemszögéből nézve a vector többi művelete vagy ugyanúgy viselkedik, 
mint az eddig bemutatottak (mivel hasonló módon foglalnak le és szabadítanak fel erőfor- 
rásokat), vagy megvalósításuk egyszerű (mert nem végeznek olyan tevékenységet, amely- 
ben az érvényes állapot fenntartása problémát okozhatna). A legtöbb osztályban ezek a , tri- 
viális" függvények jelentik a döntő többséget. Az ilyen eljárások bonyolultsága elsősorban 
attól függ, hogy a konstruktor milyen működési környezetet biztosít számukra. Másképpen 
fogalmazva, az általános tagfüggvények bonyolultsága elsősorban a jó osztályinvariáns 
megválasztásán múlik (424.3.7.1). Az egyszerű vektorműveletek vizsgálatával megérthetjük, 
mitől lesz jó egy osztályinvariáns és hogyan kell megírnunk a konstruktorokat ahhoz, hogy 
ezeket az invariánsokat biztosítsák. 


Az olyan műveleteket, mint a vektorok indexelése (416.3.3) azért könnyű megvalósítani, 
mert erősen építenek arra az invariánsra, amit a konstruktor hoz létre és az erőforrásokat 
lefoglaló, illetve felszabadító függvények tartanak fenn. Az indexelő művelet például hivat- 
kozhat a v tömbre, amely az elemeket tárolja: 


templatex class T, class Az 
IG vectorcST,A2::operatorl (size type i) 
t 

return ulij; 


] 


Nagyon fontos és alapvető szabály, hogy a konstruktornak kell lefoglalnia az erőforrásokat 
és biztosítania kell egy egyszerű invariánst. Ahhoz, hogy ennek fontosságát megértsük, néz- 
zük meg a vector. base definíciójának alábbi változatát: 


templatecxciass T;, class A - allocatorST: : // a konstruktor esetlen használata 
class vector. base ( 


bublic: 
A alloc; // memóriafoglaló 
T" u; // a lefoglalt terület eleje 
T" space; // az elemsorozat vége, bővítés számára tartalékolt terület kezdete 


T" last; // a lefoglalt terület vége 
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vector. base(const AG a, typename A::size type n) : alloc(a), v(O), space(0O), last(0) 
( 

v — alloc.allocate(n); 

space - last — van; 


J 


-vector. baseO t if (v) alloc.deallocate(v, last-v); ) 
] 


Itt a vector. base objektumot két lépésben hozzuk létre. Először egy , biztonsági állapotot" 
alakítunk ki, amely a 2, a space és a last változót O-ra állítja, és csak ezután próbálunk me- 
móriát foglalni. Ez arra az indokolatlan félelemre vezethető vissza, hogy az elemek lefogla- 
lása közben keletkező kivételek miatt félig létrejött objektumot hozhatunk létre. A félelem 
azért indokolatlan, mert ilyen objektumot egyáltalán nem hozhatunk létre. A szabályok, 
melyek a statikus, automatikus, illetve tagobjektumok és a standard könyvtár tárolóinak 
elemeire vonatkoznak, megakadályozzák ezt. Azokban a szabvány előtti könyvtárakban 
azonban, melyek a tárolókban elhelyező new operátort (§10.4.11) használtak (használnak) 
az objektumok létrehozására és nem foglalkoztak (foglalkoznak) a kivételbiztossággal, ez 
előfordulhatott (előfordulhat). A megrögzött szokásokon nehéz változtatni. 

Figyeljük meg, hogy a biztonságosabb program előállítására irányuló próbálkozás tovább 
bonyolítja az osztályinvariánst: nem lehetünk biztosak abban, hogy a v egy létező, lefoglalt 
memóriaterületre mutat, mert szerepelhet benne a Oérték is. Ez a hiba azonnal megbosszul- 
ja magát. A standard könyvtár nem követeli meg a memóriafoglalóktól, hogy egy 0 értéket 
tartalmazó mutatót biztonságosan szabadítsanak fel (419.4.19. A memóriafoglalók ebben el- 
térnek a delete művelettől (46.2.6). Ebből következik, hogy a destruktorban külön ellenőr- 
zést kell végeznünk. Ezenkívül minden elemnek kezdőértéket adunk és csak később értel- 
mes értéket. Ezen költségek egy olyan elemtípus esetében lehetnek jelentősek, ahol az 
értékadás bonyolult, például a szring vagy a list osztálynál. 


A kétlépéses létrehozás nem szokatlan megoldás. Gyakran olyan formában jelenik meg, 
hogy a konstruktor csak egy , egyszerű és biztonságos" kezdeti értékadást végez, mellyel az 


objektum törölhető állapotba kerül. A valódi kezdeti értékadást egy initŐ függvény végzi 
el, melyet a felhasználónak külön meg kell hívnia: 


templatexclass T- // régies (szabvány és kivételkezelés előtti) stílus 
class vector. base ( 
public: 
T" u; // a lefoglalt terület eleje 
T" space; // az elemsorozat vége, bővítés számára tartalékolt terület kezdete 


T" last; // a lefoglalt terület vége 
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vector. baseO : v(0), space(0), last(0O) t ) 
-—vector. baseO t free(1; ) 


boolinit(siíze tn)  // igazat ad vissza, ha a kezdeti értékadás sikerült 
( 
if (v - (T9malloc(sizeojCID mn)) tí 
uninitialized  fillív,v4n, TO; 
space - last — van; 
return true; 
) 
return false; 
) 
FA 


Ezen stílus látható előnyei a következők: 


1. A konstruktor nem válthat ki kivételt és az initO segítségével megvalósított kez- 
deti értékadás sikerességét a ,szokásos" módszerekkel (azaz nem kivételekkeD 
ellenőrizhetjük. 

2. Érvényes állapot áll rendelkezésünkre, melyet bármely művelet komoly problé- 
ma esetén is biztosítani tud. 

3. Az erőforrások lefoglalását mindaddig halaszthatjuk, amíg ténylegesen szüksé- 


günk nincs kezdőértékkel rendelkező objektumokra. 


A következő részfejezetekben ezeket a szempontokat vizsgáljuk meg és bemutatjuk, hogy 
a kétlépéses létrehozás miért nem biztosítja az elvárt előnyöket, amellett, hogy más problé- 
mákat is felvet. 


E.3.5.1. Az init() függvény használata 


Az első pont (az initO eljárás használata a konstruktor helyet9) valójában nem is előny. 
A konstruktorok és kivételek használata sokkal általánosabb és rendezettebb megoldás az 
erőforrás-lefoglalási hibák és a kezdeti értékadással kapcsolatos problémák kezelésére 
(414.1, §14.4)9. Ez a stílus a kivételek nélküli Ct- maradványa. 


Ha a két stílusban ugyanolyan figyelmesen írunk meg egy programot, azt tapasztalhatjuk, 
hogy két, szinte teljesen egyenértékű eredményt kapunk. Az egyik: 


int fIGint n) 
jó 
vector£XxX2 v; 


11 sze 
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if (v.init(n)) ( 
// "vu" n elem vektora 
) 
else ( 
// a probléma kezelése 
) 
) 


Míg másik változat: 


int f2Cint n) 
try ( 
vector V2X5 (n); 
ése 
// "v n elem vektora 
) 
catch (...) ( 
// a probléma kezelése 


J 


A külön initŐ függvény használata viszont , lehetőséget" ad az alábbi hibák elkövetésére: 


Elfelejtjük meghívni az initŐ függvényt (410.2.3). 

Elfelejtjük megvizsgálni, hogy az initO sikerrel járt-e. 

Elfelejtjük, hogy az init0 kivételeket válthat ki. 

Használni kezdünk egy objektumot, mielőtt meghívnánk az initO eljárást. 


saga ők zadlét elé Eza 


A vectorcsT:::initŐ definíciója a /3/ pontra mutat példát. 


Egy jó Ct4-változatban az /20 egy kicsit gyorsabb is, mint az /70, mert az általános eset- 
ben nem végez ellenőrzést. 


E.3.5.2. Alapértelmezett érvényes állapot 
A második pont (miszerint egy könnyen előállítható, , alapértelmezett" érvényes állapot áll 
rendelkezésünkre) általában tényleg előny, de a vector esetében ez felesleges költségeket 
jelent, ugyanis elképzelhető olyan vector. base, ahol v--0 és a vector megvalósításának 
mindenhol védekeznie kell ez ellen: 


templatex class T- 
IG vectorST5::operatorl[[(size t i) 
( 
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if (v) return ulij; 
// hibakezelés 


Ha megengedjük a v--0 állapotot, a tartomány-ellenőrzés nélküli indexelés ugyanolyan 
lassú lesz, mint az ellenőrzött hozzáférés: 


templatexK class T- 
IG vectorcsT5::at(size tí) 
( 
if (iSv.sizeO) return ulil; 
throw out of range("vector index"); 


] 


Itt alapjában véve annyi történt, hogy a vector. base eredeti invariánsát túlbonyolítottuk, az- 
zal, hogy bevezettük a v--0 lehetőséget. Ennek következtében a vecztor eredeti invariánsát 
is ugyanígy kellett módosítanunk, tehát a vector és a vector. base minden eljárását bonyo- 
lultabban kell megfogalmaznunk. Ez számtalan hiba forrása lehet, például nehezebb lesz 
a kód módosítása és a program lassabban fog futni. Gondoljunk arra, hogy a modern kiépí- 
tésű számítógépeknél a feltételes utasítások meglepően költségesek lehetnek. Ha fontos 
a hatékonyság, a kulcsműveletek -— például a vektorindexelés — feltételes utasítások nélkü- 


li megvalósítása elsőrendű követelmény lehet. 


Érdekes módon, már a vector. base eredeti meghatározása is biztosít egy könnyen létrehoz- 
ható érvényes állapotot. Csak akkor létezhet egy vector. base objektum, ha a kezdeti hely- 
foglalás sikeres volt. Ebből következik, hogy a vector írójának biztosítania kell egy , vészki- 
járat" függvényt, például a következő formában: 


templatex class T; class Az 

void vectorST, A2::emergency exit 

€ 
sbace-uw; —— // "this méretének 0-ra állítása 
throw Total failureO; 

J 


Ez a megoldás túlságosan drasztikus, mert nem hívja meg az elemek destruktorait és nem 
szabadítja fel a vector. base objektumban az elemek által elfoglalt területet. Röviden fogal- 
mazva, nem nyújt alapbiztosítást (SE.2). Ha figyelünk a v és a sbace adattag tartalmára és az 
elemek destruktoraira, elkerülhetjük az erőforrás-lyukak kialakulását: 


templatex class T; class Az 
void vectorST,A2::emergency exitO 


( 
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destroy elementsO; // takarítás 
throw Total failurcO; 
) 


Figyeljük meg, hogy a szabványos vector olyan egyszerű szerkezet, amely a lehető legki- 
sebbre csökkenti a kétlépéses létrehozás miatt jelentkező problémák lehetőségét. Az initO 
függvény szinte egyenértékű a resizeO eljárással, a v--0 lehetőséget pedig a legtöbb eset- 
ben a size0--0 vizsgálat elvégzésével is kezelhetjük. A kétlépéses létrehozás eddig bemu- 
tatott negatív hatásai még erősebben jelentkeznek, ha programunkban szerepel egy olyan 
osztály, amelynek jelentős erőforrásokra — például hálózati kapcsolatra vagy külső állomá- 
nyokra - van szüksége. Ezek az osztályok ritkán képezik egy olyan keretrendszer részét, 
amely felügyeli használatukat és megvalósításukat, olyan formában, ahogy a standard 
könyvtár követelményei felügyelik a vector használatát. A problémák száma még tovább 
növekszik, ha az alkalmazás céljai és a megvalósításukhoz szükséges erőforrások kapcso- 
lata bonyolult. Nagyon kevés olyan osztály van, amely annyira közvetlenül kapcsolódik 
a rendszer erőforrásaihoz, mint a vector. 


Az egyszerű , biztonságos állapot" létezésének elve alapjában véve nagyon hasznos. Ha egy 
objektumot nem tudunk érvényes állapotba állítani anélkül, hogy kivételektől kellene tar- 
tanunk a művelet befejezése előtt, valóban problémáink lehetnek. A , biztonságos állapot- 
nak" viszont az osztály szerepéhez természetesen kell kapcsolódnia, nem erőltetett módon, 
az osztály invariánsát bonyolítva. 


E.3.5.3. Az erőforrás-lefoglalás késleltetése 


A második ponthoz hasonlóan (§E.3.5.2) a harmadik is egy jó ötlet rossz megvalósítása, ami 
nyereség helyett inkább veszteséget eredményez. A legtöbb esetben -— különösen az olyan 
tárolókban, mint a vector — az erőforrás-lefoglalás késleltetésének legjobb módja a progra- 
mozó számára az, hogy magát az objektumot hozza létre, amikor szüksége van rá. Nézzük 
meg például a vector objektum alábbi felhasználását: 


void (int n) 
t 
vectorSX2 un); — // n darab alapértelmezett X típusú objektum létrehozása 
JV ét 
vl3] - X(999; // v[3] igazi "kezdeti értékadása" 
sea 
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Nagy pazarlás egy X típusú objektumot csak azért létrehozni, mert valamikor, később érté- 
ket fogunk adni neki. Különösen nagy a veszteség, ha az X osztályra az értékadás költséges 
művelet. Ezért az X kétlépéses létrehozása előnyösnek tűnhet. Az X maga is lehet egy 
vector, ezért a vector kétlépéses létrehozásától az üres vektorok létrehozási költségeinek 
csökkentését remélhetjük, az alapértelmezett (üres) vektorok létrehozása azonban már 
egyébként is elég hatékony, ezért felesleges a megvalósítást azzal bonyolítanunk, hogy az 
üres vektort külön esetként kezeljük. Általánosabban fogalmazva, a felesleges kezdeti ér- 
tékadások elkerülésére ritkán jelent tökéletes megoldást az, hogy a konstruktorból kiemel- 
jük az összetettebb kezdeti értékadásokat: 


void fXint n) 
t 
vectorSX5 u; // üres vektor létrehozása 
VAA 
v.push back(X(99)9; // elemek létrehozása, amikor szükséges 
MI .. 
) 


Összefoglalva: a kétlépéses létrehozás sokkal bonyolultabb osztályinvariánshoz és általá- 
ban kevésbé elegáns, több hibalehetőséget tartalmazó és nehezebben kezelhető program- 
hoz vezet. Ezért a nyelv által támogatott , konstruktor elv" jobban használható, mint az 
, initŐ függvényes megoldás". Tehát az erőforrásokat mindig a konstruktorban foglaljuk le, 
ha a késleltetett erőforrás-lefoglalást nem teszi kötelezővé maga az osztály természete. 


E.4. A szabványos tárolók garanciái 


Ha a könyvtár valamelyik művelete önmaga vált ki kivételt, akkor biztosítani tudja — és biz- 
tosítja is —, hogy az általa használt objektumok érvényes állapotban maradnak. A vector ese- 
tében például az at0 függvény (§16.3.3) képes kiváltani egy out of range kivételt, ez azon- 
ban nem jelent problémát a vektor kivételbiztossága szempontjából. Az at0 függvény 
megírójának nem jelent problémát, hogy a vektort érvényes állapotba állítsa a kivétel kivál- 
tása előtt. Problémák csak akkor jelentkeznek — a könyvtár megvalósítói, a könyvtár fel- 
használói, illetve azok számára, akik megpróbálják megérteni a programot -, amikor fel- 
használói eljárások váltanak ki kivételt. 


A standard könyvtár tárolói alapbiztosítást nyújtanak (VE.2): a könyvtár alap invariánsai 
mindig megmaradnak és ha a felhasználó a követelményeknek megfelelően jár el, nem ke- 
letkeznek erőforrás-lyukak sem. A felhasználói eljárásoktól azt követeljük meg, hogy ne 
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hagyják a tárolók elemeit érvénytelen állapotban és a destruktorok ne váltsanak ki kivételt. 
Az eljárásokon most azokat a függvényeket értjük, melyeket a standard könyvtár megvaló- 
sításában felhasználunk, tehát a konstruktorokat, az értékadásokat, a destruktorokat, illetve 
a bejárók műveleteit (VE.4.4). 


A programozó ezeket a műveleteket könnyen megírhatja a könyvtár elvárásainak megfele- 
lően. A követelményeket általában akkor is kielégítik eljárásaink, ha nem tudatosan figye- 
lünk rájuk. A következő típusok biztosan kielégítik a standard könyvtár követelményeit 
a tárolók elemtípusaira vonatkozóan: 


1. A beépített típusok, köztük a mutatók 

2. Azok a típusok, melyek nem tartalmaznak felhasználói műveleteket 

3. Az olyan műveletekkel rendelkező osztályok, melyek nem váltanak ki kivétele- 
ket és nem hagyják operandusaikat érvénytelen állapotban 

4. Azok az osztályok, melyek destruktora nem vált ki kivételt, és amelyeknél 
könnyen ellenőrizhető, hogy a standard könyvtár által használt eljárások (a 
konstruktorok, az értékadások, a c, az —— és a swabpO függvény) nem hagyják 
operandusaikat érvénytelen állapotban 


Azt is ellenőriznünk kell minden esetben, hogy a műveletek ne hozzanak létre erőforrás- 
lyukakat: 


void KCircle" pc, Triangle" pt, vectorcShape"26 v2) 


t 
vectorcShape"2 v(109; // vektor létrehozása vagy bad alloc kivétel kiváltása 
vl3] — pc; // nem vált ki kivételt 
v.insert(v.beginO0t4á pb; — // vagy beszúrja a pt elemet, vagy nincs hatása v-re 
v2.erase(v2.begin0t3);  / vagy törli v2/3]-t, vagy nincs hatása v2-re 
2 - u; // vagy átmásolja v-t, vagy nincs hatása v2-re 
VAK 

4) 


Amikor az /Ó futása véget ér, v szabályosan törlődni fog, míg 12 érvényes állapotban lesz. 
A fenti részlet nem mutatja, ki felel a bc és a bt törléséért. Ha /0 a felelős, akkor vagy el kell 
kapnia a kivételeket és így kezelni a szükséges törléseket, vagy a mutatókat lokális auto ptr 


változókhoz kell kötnie. 


Ennél érdekesebb kérdés, mikor ad a könyvtár erős biztosítást, azaz mely műveletek mű- 
ködnek úgy, hogy vagy sikeresen futnak le, vagy semmilyen változtatást nem hajtanak vég- 
re operandusaikon. 
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Például: 


void f(vectorSX2G ux) 
t 

vx.insert(vx.begin 044, XC719); /7 elem hozzáadása 
) 


Általában az X műveletei és a vectorcX- osztály memóriafoglalója válthat ki kivételt. Mit 
mondhatunk a ux elemeiről, ha az /Ö függvény futása kivétel következtében szakad meg? 
Az alapbiztosítás garantálja, hogy erőforrás-lyukak nem keletkeznek és a ux elemei érvé- 
nyes állapotban maradnak. De pontosan milyen elemekről van szó? Elképzelhető, hogy egy 
elem azért törlődik, mert az insertő csak így tudja az alapbiztosítás követelményeit vissza- 
állítani? Gyakran nem elég annyit tudnunk, hogy a tároló jó állapotban van, pontosan tud- 
ni akarjuk azt is, milyen állapotról van szó. A kivétel kezelése után általában tisztában sze- 
retnénk lenni azzal, hogy milyen elemek szerepelnek a vektorban, mert ellenkező esetben 
komolyabb hibakezelést kellene végeznünk. 


E.4.1. Elemek beszúrása és törlése 


Az elemek beszúrása egy tárolóba, illetve az elemek törlése onnan nyilvánvaló példája azon 
műveleteknek, melyek a tárolót megjósolhatatlan állapotban hagyhatnák egy kivétel bekö- 
vetkezésekor. Ennek oka leginkább az, hogy a beszúrás és a törlés során sok olyan műve- 
letet hajtunk végre, amely kivételt válthat ki: 


Új értéket másolunk a tárolóba. 

A tárolóból eltávolított elemet meg is kell semmisítenünk. 

Az új elem tárolásához néha memóriát is kell foglalnunk. 

A vector és a degue elemeit néha új helyre kell áthelyeznünk. 

Az asszociatív tárolók összehasonlító eljárásokat alkalmaznak az elemekre. 


ESÉSE SHESZ SEN As st 


Sok beszúrás és törlés esetében bejáró műveleteket is végre kell hajtanunk. 


Ezek a műveletek mind okozhatnak kivételeket, ezt semmilyen biztosítás (JE.2) nem aka- 
dályozza meg. Ahhoz, hogy ezekre az esetekre valamilyen biztosítást nyújtsunk, elviselhe- 
tetlenül költséges eljárásokra lenne szükség. Ennek ellenére a könyvtár védi magát — és 
a felhasználókat — a többi, felhasználói függvény kivételeitől. 


Amikor láncolt adatszerkezeteken végzünk műveleteket (például egy /ist-en vagy map-en), 
úgy szúrhatunk be és távolíthatunk el elemeket, hogy a tároló többi elemére nem vagyunk 
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hatással. Ugyanez nem valósítható meg az olyan tárolókban, ahol több elem számára egyet- 
len, folytonos memóriaterületet foglalunk le (például a vector és a degue esetében). Ilyen- 
kor az elemeket néha új helyre kell mozgatnunk. 


Az alapbiztosításon túl a standard könyvtár erős biztosítást is nyújt néhány olyan művelet- 
hez, amely elemeket szúr be vagy töröl. Mivel a láncolt adatszerkezetekkel megvalósítható 
tárolók ebből a szempontból jelentősen eltérnek az elemek tárolásához folytonos memória- 
területet használóktól, a standard könyvtár teljesen más garanciákat ad a különböző 
tárolófajtákhoz: 


1. Garanciák a vector (§16.3) és a degue (§17.2.3) osztályra: 

e Ha egy push backO vagy egy push frontO művelet okoz kivételt, akkor az 
nem változtatja meg operandusait. 

e Ha egy insertO utasítás vált ki kivételt és azt nem egy elem másoló 
konstruktora vagy értékadó művelete okozta, akkor az sem változtat 
operandusain. 

e Az erase() művelet csak akkor vált ki kivételt, ha azt az elemek másoló 
konstruktora vagy értékadó művelete okozza. 

e A pop bacRÓO és a pop frontO nem okoz kivételt. 

2. A list (§17.2.2) garanciái: 

e Ha egy bush backRO vagy bush frontO művelet vált ki kivételt, akkor a függ- 
vény hatástalan. 

e Ha az insertŐ okoz kivételt, akkor az nem változtatja meg operandusait. 

e Az erase0), a pop bacRO), a pop frontO), a spliceO és a reverseO sohasem vált 
ki kivételt. 

e "Ha a predikátumok és az összehasonlító függvények nem okoznak kivételt, 
akkor a list osztály removeO, remove ifO, unigueO, sortO) és mergeg eljárá- 
sai sem válthatnak ki kivételt. 

3. Garanciák asszociatív tárolókra (§17.4): 

e Ha egy elem beszúrása közben az insertŐ kivételt vált ki, akkor a függvény 
hatástalan. 

e Az erase0 nem okozhat kivételt. 


Jegyezzük meg, hogy ha erős biztosítás áll rendelkezésünkre egy tároló valamelyik műve- 
letében, akkor minden bejáró, az elemekre hivatkozó összes mutató és hivatkozás (referen- 


cia) érvényes marad kivétel bekövetkezése esetén is. 


A szabályokat egy táblázatban foglalhatjuk össze: 
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A tárolóműveletek garanciái 








vector 


degue 


list 


map 











clearO 

eraseO 

1 elemű insertŐ 
N elemű insertŐ 
mergeO 

bush backO 
bush frontO 
bop. backO 
bop frontO 
removeO 
remove ifO 
reverse 


spliceO 
swapO 


unigueO 


nem lehet kivétel 
(másolás) 

nem lehet kivétel 
(másolás) 

erős 

(másolás) 

erős 

(másolás) 


erős 


nem lehet kivétel 


nem lehet kivétel 





nem lehet kivétel 
(másolás) 

nem lehet kivétel 
(másolás) 

erős 

(másolás) 

erős 

(másolás) 


erős 
erős 
nem lehet kivétel 


nem lehet kivétel 


nem lehet kivétel 





nem lehet kivétel 


nem lehet kivétel 


erős 


erős 


nem lehet kivétel 
(összehasonlítás) 
erős 
erős 
nem lehet kivétel 
nem lehet kivétel 
nem lehet kivétel 
Cösszehasonlítás) 
nem lehet kivétel 
(predikátum) 

nem lehet kivétel 


nem lehet kivétel 





nem lehet kivétel 


nem lehet kivétel 


(összehasonlítás) 





nem lehet kivétel 


nem lehet kivétel 


erős 


alap 


nem lehet kivétel 
(összehasonlítás 
másolása) 
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A táblázat elemeinek jelentése: 


alap A művelet csak alapbiztosítást nyújt (§E.29. 
erős A művelet erős biztosítást nyújt (§E.2). 


nemlehet kivétel A művelet nem válthat ki kivételt (V4E.2). 
— A művelet ebben a tárolóban nem szerepel tagfüggvényként. 


Ahol a biztosítás megköveteli, hogy a felhasználó által megadott bizonyos műveletek ne 
váltsanak ki kivételt, ott a biztosítás alatt zárójelben feltüntettük, milyen műveletekre kell fi- 
gyelnünk. Ezek a követelmények pontosan megegyeznek a táblázat előtt, szövegesen meg- 
fogalmazott feltételekkel. 


A swapO függvények abban különböznek a többi eljárástól, hogy nem tagfüggvények. 
A clearÓ függvényre vonatkozó garancia az erase0 biztosításából következik. (§16.3.06) 
A táblázatban az alapbiztosításon túli szolgáltatásokat tüntettük fel, tehát nem szerepelnek 
azok az eljárások (például a reverse vagy a unigueO a vector osztályra), melyek további 
biztosítás nélkül valósítanak meg valamilyen algoritmust az összes sorozatra. 


A  majdnem-tároló" basic string (§17.5, §20.3) minden műveletére garantálja az alapbiztosí- 
tást (§E.5.19. A szabvány azt is biztosítja, hogy a basic string osztály erase0 és swapO eljárá- 
sa nem okoz kivételt, az insertŐ és a bush backO függvényre pedig erős biztosítást kapunk. 


Az erős biztosítást nyújtó eljárásokban amellett, hogy a tároló változatlan marad, az összes 
bejáró, mutató és referencia is érvényes marad: 


void updatel(mapsstring, X26 m, mapsstring, X2::iterator current) 
t 
XX; 
string s; 
while (cin:3s22x) 
try ( 
current - m.insert(current make pair(s,x)); 
f4 
catch(C...) ( 
// itt a "current" még mindig az aktuális elemet jelöli 


Z 
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E.4.2. Garanciák és kompromisszumok 


Az alapbiztosításon túli szolgáltatások összevisszaságai a megvalósítási lehetőségekkel ma- 
gyarázhatók. A programozók azt szeretnék leginkább, hogy mindenhol erős biztosítás áll- 
jon rendelkezésükre a lehető legkevesebb korlátozás mellett, de ugyanakkor azt is elvárják, 
hogy a standard könyvtár minden művelete optimálisan hatékony legyen. Mindkét elvárás 
jogos, de sok művelet esetében lehetetlen egymással párhuzamosan megvalósítani. Ahhoz, 
hogy jobban megvilágítsuk az elkerülhetetlen kompromisszumokat, megvizsgáljuk, milyen 
módokon lehet egy vagy több elemet felvenni egy listába, vektorba vagy map-be. 


Nézzük először, hogy egy elemet hogyan vihetünk be egy listába vagy egy vektorba. Szo- 
kás szerint, a bush backO nyújtja a legegyszerűbb lehetőséget: 


void f(IisIZX26 lst, vectorZX26 vec, const XG x) 
t 
try ( 
Istpush back(c0); // hozzáadás a listához 
) 
catch (...) ( 
// Ist változatlan 
return; 
) 
try ( 
vec.push back(x); // hozzáadás a vektorhoz 
) 
catch (...) ( 
// vec változatlan 
return; 
) 
// Ist és vec egy-egy x értékű új elemmel rendelkezik 


] 


Az erős biztosítás megvalósítása ez esetben egyszerű és , olcsó". Az eljárás azért is hasznos, 
mert teljesen kivételbiztos megoldást ad az elemek felvételére. A push backO azonban 
asszociatív tárolókra nem meghatározott: a map osztályban nincs backO. Egy asszociatív tá- 
roló esetében az utolsó elemet a rendezés határozza meg, nem a pozíció. 


Az insertŐ függvény garanciái már kicsit bonyolultabbak. A gondot az jelenti, hogy az 
insertŐ műveletnek gyakran kell egy elemet a tároló ,közepén" elhelyeznie. Láncolt adat- 
szerkezeteknél ez nem jelent problémát, tehát a list és a map egyszerűen megvalósítható, 
a vector esetében azonban előre lefoglalt terület áll rendelkezésünkre, a vectorcX2::insertŐ 
függvény egy átlagos megvalósítása pedig a beszúrási pont utáni elemeket áthelyezi, hogy 
helyet csináljon az új elem számára. Ez az optimális megoldás, de arra nincs egyszerű mód- 
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szer, hogy a vektort visszaállítsuk eredeti állapotába, ha valamelyik elem másoló értékadá- 
sa vagy másoló konstruktora kivételt vált ki (lásd §E.8[10-11], ezért a vector azzal a feltétel- 
lel ad biztosításokat, hogy az elemek másoló konstruktora nem vált ki kivételt. A list és 
a map osztálynak nincs szüksége ilyen korlátozásra, ezek könnyedén be tudják illeszteni az 
új elemet a szükséges másolások elvégzése után. 


Példaképpen tételezzük fel, hogy az X másoló konstruktora és másoló értékadása egy 
X::cannot copy kivételt vált ki, ha valamilyen okból nem sikerül létrehoznia a másolatot: 


void K(IisIZX26 lIst, vectorZX26 vec, mapcsstring,X26 m, const XG x, const string6 5) 
já 
try ( 
lst.insert(Ist.beginŐ, x); // hozzáadás a listához 
) 
catch C...) ( 
// ist változatlan 
return; 
) 
try ( 
vec.insert(vec.beginŐ, x); // hozzáadás a vektorhoz 
] 
catch (X::cannot copy) ( 
// hoppá: vec vagy rendelkezik, vagy nem rendelkezik űj elemmel 
return; 
) 
catch C(...) ( 
// vec változatlan 
return; 
) 
try ( 
m.insertrmake pair(s,x)); // hozzáadás az asszociatív tömbhöz 
] 
catch C(...) ( 
// m változatlan 
return; 
) 
// ist és vec egy-egy x értékű új elemmel rendelkezik 
// m egy új (s,x) értékű elemmel rendelkezik 


Ha X::cannot copy kivételt kapunk, nem tudhatjuk, hogy az új elem bekerült-e a vec táro- 
lóba. Ha sikerült beilleszteni az elemet, az érvényes állapotban lesz, de pontos értékét nem 
ismerjük. Az is elképzelhető, hogy egy X::cannot copy kivétel után néhány elem , titokza- 
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tosan" megkettőződik (ásd Y§E.8[11D, másik megvalósítást alkalmazva pedig a vektor végén 
lévő elemek tűnhetnek el, mert csak így lehet biztosítani, hogy a tároló érvényes állapotban 
maradjon és ne szerepeljenek benne érvénytelen elemek. 


Sajnos az erős biztosítás megvalósítása a vector osztály insertO) függvénye esetében lehetet- 
len, ha megengedjük, hogy az elemek másoló konstruktora kivételt váltson ki. Ha egy vek- 
torban teljesen meg akarnánk védeni magunkat az elemek áthelyezése közben keletkező 
kivételektől, a költségek elviselhetetlenül megnőnének az egyszerű, alapbiztosítást nyújtó 
megoldáshoz képest. 


Sajnos nem ritkák az olyan elemtípusok, melyek másoló konstruktora kivételt eredményez- 
het. Már a standard könyvtárban is találhatunk példát: a vectorcstring:, a vectorz 
vectorZdouble: 5 és a mapsstring, int: is ilyen. 


A list és a vector tároló ugyanolyan biztosítást ad az insertÖ0 egyelemű és többelemű válto- 
zatához, mert azok megvalósítási módja azonos. A map viszont erős biztosítást ad az egy- 
elemű beszúráshoz, míg a többeleműhöz csak alapbiztosítást. Az egyelemű insertŐ a map 
esetében könnyen elkészíthető erős biztosítással, a többelemű változat egyetlen logikus 
megvalósítási módja azonban a map esetében az, hogy az új elemeket egymás után szúrjuk 
be, és ehhez már nagyon nehéz lenne erős garanciákat adni. A gondot itt az jelenti, hogy 
nincs egyszerű visszalépési lehetőség (nem tudunk korábbi sikeres beszúrásokat visszavon- 
ni), ha valamelyik elem beszúrása nem sikerül. 


Ha olyan többelemű beszúró műveletre van szükségünk, amely erős biztosítást ad, azaz 
vagy minden elemet hibátlanul beilleszt, vagy egyáltalán nem változtatja meg a tárolót, leg- 
egyszerűbben úgy valósíthatjuk meg, hogy egy teljesen új tárolót készítünk, majd ennek si- 
keres létrehozása után egy swabO műveletet alkalmazunk: 


templatecciass GC, class Iter: 
void safe insert((CG c, typename C::const iterator i, Iter begin, Iter end) 


t 
C tmp(c.beginŐ, UV; // az elöl levő elemek másolása ideiglenes változóba 
copy(begin, end, inserter(tmp,tmp.endO); // új elemek másolása 
copy(i, c.endO, inserter(tmp, tmp.endO)); // a záró elemek másolása 
swap(c, tmp); 
J 


Szokás szerint, ez a függvény is hibásan viselkedhet, ha az elemek destruktora kivételt vált 
ki, ha viszont az elemek másoló konstruktora okoz hibát, a paraméterben megadott tároló 
változatlan marad. 
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E.4.3. A swap() 


A másoló konstruktorokhoz és értékadásokhoz hasonlóan a swap eljárások is nagyon fon- 
tos szerepet játszanak sok szabványos algoritmusban és közvetlenül is gyakran használják 
a felhasználók. A sortO és a stable sortO például általában a swapO segítségével rendezi át 
az elemeket. Tehát ha a swapO kivételt vált ki, miközben a tárolóban szereplő értékeket 
cserélgeti, akkor a tároló elemei a csere helyett vagy változatlanok maradnak, vagy megket- 


tőződnek. 


Vizsgáljuk meg a standard könyvtár swapO függvényének alábbi, egyszerű megvalósítását 


(418.6.99: 


templatecxcilass T- void swap(I€6 a, T6 b) 


t 
T tmp — a; 
a —- b; 
b - tmp; 

J 


Erre teljesül, hogy a swapO csak akkor eredményezhet kivételt, ha azt az elemek másoló 
konstruktora vagy másoló értékadása váltja ki. 


Az asszociatív tárolóktól eltekintve a szabványos tárolók biztosítják, hogy a swapO függ- 
vény ne váltson ki kivételeket. A tárolókban általában úgy is meg tudjuk valósítani a swapO 
függvényt, hogy csak az adatszerkezeteket cseréljük fel, melyek mutatóként szolgálnak 
a tényleges elemekhez (§13.5, §17.1.39. Mivel így magukat az elemeket nem kell mozgat- 
nunk, azok konstruktorára vagy értékadó műveletére nincs szükségünk, tehát azok nem 
kapnak lehetőséget kivétel kiváltására. Ezenkívül a szabvány biztosítja, hogy a könyvtár 
swapO függvénye nem tesz érvénytelenné egyetlen hivatkozást, mutatót és bejárót sem 
azok közül, melyek a felcserélt tárolók elemeire hivatkoznak. Ennek következtében kivéte- 
lek egyetlen ponton léphetnek fel: az asszociatív tárolók összehasonlító objektumaiban, 
melyeket az adatszerkezet leírójának részeként kell másolnunk. Tehát az egyetlen kivétel, 
amit a szabványos tárolók swapO eljárása eredményezhet, az összehasonlító objektum má- 
soló konstruktorából vagy értékadó műveletéből származik (417.1.4.1). Szerencsére az 
összehasonlító objektumoknak általában annyira egyszerű másoló műveleteik vannak, 
hogy nincs lehetőségük kivétel kiváltására. 


A felhasználói swapO függvények viszonylag egyszerűen nyújthatnak ugyanilyen biztosítá- 
sokat, ha gondolunk rá, hogy , mutatókkal" ábrázolt adatok esetében elegendő csak a mu- 
tatókat felcserélnünk, ahelyett, hogy lassan és precízen lemásolnánk a mutatók által kijelölt 
tényleges adatokat (§13.5, §16.3.9, §17.1.2). 
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E.4.4. A kezdeti értékadás és a bejárók 


Az elemek számára való memóriafoglalás és a memóriaterületek kezdeti értékadása alapve- 
tő része minden tárolónak (§E.3). Ebből következik, hogy a fel nem töltött (előkészítetlen) 
memóriaterületen objektumot létrehozó szabványos eljárások — az uninitialized fill0, az 
uninitialized fill n0Ő és az uninitialized copyO (419.4.4) — semmiképpen sem hagyhatnak 
létrehozott objektumokat a memóriában, ha kivételt váltanak ki. Ezek az algoritmusok erős 
biztosítást valósítanak meg (YE.2), amihez gyakran kell elemeket törölni, tehát az a követel- 
mény, miszerint a destruktoroknak tilos kivételt kiváltaniuk, elengedhetetlen ezeknél 
a függvényeknél is (lásd §E.8[14]). Ezenkívül azoknak a bejáróknak is megfelelően kell vi- 
selkedniük, melyeket paraméterként adunk át ezeknek az eljárásoknak. Tehát érvényes be- 
járóknak kell lenniük, érvényes sorozatokra kell hivatkozniuk, és a bejáró műveleteknek 
(például a 4-4, a /- vagy a foperátornak) nem szabad kivételt kiváltaniuk, ha érvényes be- 
járókra alkalmazzuk azokat. 


A bejárók (itterátorok) olyan objektumok, melyeket a szabványos algoritmusok és a szabvá- 
nyos tárolók műveletei szabadon lemásolhatnak, tehát ezek másoló konstruktora és máso- 
ló értékadása nem eredményezhet kivételt. A szabvány garantálja, hogy a szabványos táro- 
lók által visszaadott bejárók másoló konstruktora és másoló értékadása nem vált ki kivételt, 
így a vectorST:::beginŐ által visszaadott bejárót például nyugodtan lemásolhatjuk, nem kell 
kivételtől tartanunk. 


Figyeljünk rá, hogy a bejárókra alkalmazott --t vagy -- művelet eredményezhet kivételt. Pél- 
dául egy istreambuf iterator (§19.2.6) egy bemenethibát (logikusan) egy kivétel kiváltásá- 
val jelezhet, egy tartományellenőrzött bejáró pedig teljesen szabályosan jelezheti kivétellel 
azt, hogy megpróbáltunk kilépni a megengedett tartományból (419.3). Akkor azonban nem 
eredményezhetnek kivételt, ha a bejárót úgy irányítjuk át egy sorozat egyik eleméről a má- 
sikra, hogy közben a 4-4 vagy a -- egyetlen szabályát sem sértjük meg. Tehát az 
uninitialized fill0, az uninitialized fill nO és az uninitialized copyO feltételezi, hogy 
a bejárókra alkalmazott --- és -- művelet nem okoz kivételt. Ha ezt mégis megteszik, a szab- 
vány megfogalmazása szerint ezek nem is igazán bejárók, vagy az általuk megadott , soro- 
zat" nem értelmezhető sorozatként. Most is igaz, hogy a szabvány nem képes megvédeni 
a felhasználót a saját maga által okozott nem meghatározható viselkedéstől (WE.2). 


E.4.5. Hivatkozások elemekre 


Ha elemre hivatkozó mutatót, referenciát vagy bejárót adunk át egy eljárásnak, az tönkre- 
teheti a listát azzal, hogy az adott elemet érvénytelenné teszi: 
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void f(const X6 x) 
18 
listzx2 ist; 
lstpush back(x); 
listzX2::iterator i - Ist.beginO; 
tj s Xg // x listába másolása 


A-n 


Ha az x változóban érvénytelen érték szerepel, a list destruktora nem képes hibátlanul meg- 
semmisíteni az Ist objektumot: 


struct X ( 
int" p; 


XO (p - new int; ) 
-XO ( delete p; ) 


SEBE 
]: 
void maliciousO 
( 
XX 
x.p — reinterpret castsinto( 7); // hibás x 
JO; // időzített bomba 
) 


Az JO végrehajtásának befejeztével meghívódik a listSxX: destruktora, amely viszont meg- 
hívja az X destruktorát egy érvénytelen értékre. Ha megpróbáljuk a delete p parancsot vég- 
rehajtani egy olyan b értékre, amely nem O és nem is létező X típusú értékre mutat, az ered- 
mény nem meghatározható lesz és akár a rendszer azonnali összeomlását okozhatja. Egy 
másik lehetőség, hogy a memória érvénytelen állapotba kerül, ami sokkal később, a prog- 
ram olyan részében okoz , megmagyarázhatatlan" hibákat, amely teljesen független a tény- 
leges problémától. 


Ez a hibalehetőség nem gátolja meg a programozókat abban, hogy referenciákat és bejáró- 
kat használjanak a tárolók elemeinek kezelésére, hiszen mindenképpen ez az egyik legegy- 
szerűbb és leghatékonyabb módszer az ilyen feladatok elvégzéséhez. Mindenesetre érde- 
mes különösen elővigyázatosnak lennünk a tárolók elemeire való hivatkozásokkal 
kapcsolatban. Ha egy tároló épsége veszélybe kerülhet, érdemes a kevésbé gyakorlott fel- 
használók számára biztonságosabb, ellenőrzött változatokat is készítenünk, például megad- 
hatunk egy olyan eljárást, amely ellenőrzi, hogy az új elem érvényes-e, mielőtt beszúrja azt 
a fontos" tárolóba. Természetesen ilyen ellenőrzéseket csak akkor végezhetünk, ha ponto- 
san ismerjük a tárolóban tárolt elemek típusát. 
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Általában, ha egy tároló valamelyik eleme érvénytelenné válik, a tárolóra alkalmazott min- 
den további művelet hibákat eredményezhet. Ez nem csak a tárolók sajátja: bármely objek- 


tum, amely valamilyen szempontból hibás állapotba kerül, a későbbiekben bármikor okoz- 
hat problémákat. 


E.4.6. Predikátumok 


Számos szabványos algoritmus és tároló használ olyan predikátumokat, melyeket a felhasz- 
nálók adhatnak meg. Az asszociatív tárolók esetében ezek különösen fontos szerepet tölte- 
nek be: az elemek keresése és beszúrása is ezen alapul. 


A szabványos tárolók műveletei által használt predikátumok is okozhatnak kivételeket, és 
ha ez bekövetkezik, a standard könyvtár műveletei legalább alapbiztosítást nyújtanak, de 
sok esetben (például az egyelemű insertŐ műveletnél) erős biztosítás áll rendelkezésünk- 
re (§E.4.1). Ha egy tárolóján végzett művelet közben egy predikátum kivételt vált ki, elkép- 
zelhető, hogy az ott tárolt elemek nem pontosan azok lesznek, amelyeket szeretnénk, de 
mindenképpen érvényes elemek. Például ha az -— okoz kivételt a /ist::unigueO (§17.2.2.3) 
művelet végrehajtása közben, nem várhatjuk el, hogy minden értékismétlődés eltűnjön. 
A felhasználó mindössze annyit feltételezhet, hogy a listában szereplő értékek érvényesek 
maradnak (lásd YE. 5.3). 


Szerencsére a predikátumok ritkán csinálnak olyasmit, ami kivételt eredményezhet. Ennek 
ellenére a felhasználói c, ——, és /- predikátumokat figyelembe kell vennünk, amikor kivé- 
telbiztosságról beszélünk. 


Az asszociatív tárolók összehasonlító objektumairól a swapO művelet végrehajtása során 
másolat készül (VE.4.3), ezért érdemes biztosítanunk, hogy azon predikátumok másoló mű- 
veletei, melyeket felhasználhatunk összehasonlító objektumokként, ne válthassanak ki 
kivételt. 


E.5. A standard könyvtár további részei 


A kivételbiztosság legfontosabb célja, hogy fenntartsuk az objektumok épségét és követke- 
zetességét, azaz az önálló objektumok alap-invariánsa mindig igaz maradjon és az egymás- 
sal kapcsolatban álló objektumok se sérüljenek. A standard könyvtár szemszögéből nézve 
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a kivételbiztosság fenntartása a tárolók esetében a legbonyolultabb. Ha a kivételbiztosság- 
ra összpontosítunk, a standard könyvtár többi része nem túl érdekes, de a kivételbiztosság 
szempontjából a beépített tömb is egy tároló, melyet felelőtlen műveletekkel könnyen 
tönkretehetünk. 


A standard könyvtár függvényei általában csak olyan kivételeket válthatnak ki, melyeket 
meghatároznak vagy amelyeket az általuk meghívott felhasználói műveletek eredményez- 
hetnek. Emellett azok az eljárások, melyek (közvetve vagy közvetlenül) memóriát foglalnak 
le, a memória elfogyását kivétellel jelezhetik (általában az std::bad alloc kivétellel. 


E.5.1. Karakterláncok 


A string objektumokon végzett műveletek sokféle kivételt okozhatnak, a basic string vi- 
szont karaktereit a char. traits (§20.2) osztály által biztosított függvényekkel kezeli és ezek- 
nek nem szabad kivételt okozniuk. A standard könyvtár cAhuar. traits objektumai nem válta- 
nak ki kivételeket, és ha egy felhasználói char. traits valamelyik eljárása eredményez ilyet, 
azért a standard könyvtár semmilyen felelősséget nem vállal. Különösen fontos, hogy 
a basic string osztályban elemként (karakterként) használt típus nem rendelkezhet felhasz- 
nálói másoló konstruktorral és értékadással, mert így nagyon sok kivétel-lehetőségtől sza- 
badulunk meg. 


A basic string nagyon hasonlít a szabványos tárolókra (417.5, §20.39, elemei valójában egy 
egyszerű sorozatot alkotnak, melyet a basic stringcCh, Tr, A2::iterator vagy 
a basic stringZCh, Tr, A2::const iterator objektumokkal érhetünk el. Ennek következtében 
a string alapbiztosítást (§E.2) ad és az erase() az insertO, a push backO és a swapO (YE.4.1) 
függvény garanciái a basic string — osztály — esetében is érvényesek. 
A basic stringZCh, Tr, A2::push backO például erős biztosítást nyújt. 


E.5.2. Adatfolyamok 


Ha egy adatfolyamot megfelelően állítunk be, annak függvényei az állapotváltozásokat ki- 
vételekkel jelzik (421.3.09. Ezek jelentése pontosan meghatározott és nem okoznak 
kivételbiztossági problémákat. Ha egy felhasználói oberatorczO vagy operator:?0 eljárás 
okoz kivételt, az úgy jelenhet meg a programozó számára, mintha azt az iostream könyvtár 
okozta volna. Ennek ellenére ezek a kivételek nem hatnak az adatfolyam állapotára 


(421.3.39. Az adatfolyam későbbi műveletei esetleg nem találják meg az általuk várt adato- 
kat — mert egy korábbi művelet kivételt váltott ki a szabályos befejeződés helyett —, de ma- 


1298 Függelékek és tárgymutató 


ga az adatfolyam nem válik érvénytelenné. Szokás szerint az [/D problémák után szükség 
lehet a clearO függvény meghívására, mielőtt további írást vagy olvasást kezdeményeznénk 


(421.3.3, §21.3.59. 


A basic string osztályhoz hasonlóan az iostream is egy char. traits objektumra hivatkozik 
a karakterkezelés megvalósításához (420.2.1, §E.5.1), tehát feltételezheti, hogy a karaktere- 
ken végzett műveletek nem okoznak kivételt, illetve semmilyen biztosítást nem kell adnia, 
ha a felhasználó megsérti ezt a kikötést. 


Ahhoz, hogy a standard könyvtár kellően hatékony optimalizálást alkalmazhasson, feltéte- 
lezzük, hogy a locale (§D.2) és a facet(§D.3) objektumok sem okozhatnak kivételt. Ha még- 
is így működnek, akkor az azokat használó adatfolyamok érvénytelenné válhatnak. Ennek 
ellenére a leggyakoribb ilyen kivétel — az std::bad casta use facet(§D.3.1) függvényben — 
csak olyan, felhasználó által írt programrészletekben fordul elő, melyek függetlenek a szab- 
ványos adatfolyamoktól, így a legrosszabb esetben is csak a kiírás félbeszakadását vagy hi- 
bás beolvasást eredményez, az adatfolyam (legyen az akár istream, akár ostream) érvényes 
marad. 


E.5.3. Algoritmusok 


Eltekintve az uninitialized copyO, az uninitialized fillő és az uninitialized fill nO függ- 
vénytől (VE.4.4) a standard könyvtár az algoritmusokhoz alapbiztosítást (§E.2) ad. Ez azt je- 
lenti, hogy ha a felhasználó által megadott objektumok a követelményeknek megfelelően 
viselkednek, az algoritmusok fenntartják a standard könyvtár invariánsait és elkerülik az 
erőforrás-lyukakat. A nem meghatározott viselkedés elkerülése érdekében a felhasználói 
műveleteknek mindig érvényes állapotban kell hagyniuk  paramétereiket és 
a destruktoroknak nem szabad kivételeket kiváltaniuk. 


Az algoritmusok maguk nem okoznak kivételeket, ehelyett visszatérési értékükön keresz- 
tül jelzik a problémákat. A kereső algoritmusok például többnyire a sorozat végét adják 
vissza annak jelzésére, hogy nem találták meg a keresett elemet (418.2). Tehát a szabványos 
algoritmusokban keletkező kivételek valójában mindig egy felhasználói eljárásból származ- 
nak. Ez azt jelenti, hogy a kivétel vagy az egyik elemen végzett művelet — predikátum 
(418.4), értékadás vagy swapO — közben jött létre, vagy egy memóriafoglaló (419.4) okozta. 


Ha egy ilyen művelet kivételt okoz, az algoritmusok azonnal befejezik működésüket és az 
algoritmust elindító függvény feladata lesz, hogy a kivételt kezelje. Néhány algoritmus ese- 
tében előfordulhat, hogy a kivétel akkor következik be, amikor a tároló állapota a felhasz- 
náló szempontjából elfogadhatatlan. Néhány rendező eljárás például az elemeket ideigle- 


E. Kivételbiztosság a standard könyvtárban 1299 


nesen egy átmeneti tárba másolja és később innen teszi azokat vissza az eredeti tárolóba. 
Egy ilyen sortO eljárás esetleg sikeresen kimásolja az elemeket a tárolóból (azt tervezve, 
hogy hamarosan a megfelelő sorrendben írja azokat vissza), helyesen végzi el a törlést is, 
de ezután azonnal kivétel következik be. A felhasználó szempontjából a tároló teljesen 
megsemmisül, ennek ellenére minden elem érvényes állapotban van, tehát az alapbiztosí- 
tás megvalósítása egyszerű feladat. 


Gondoljunk rá, hogy a szabványos algoritmusok a sorozatokat bejárókon keresztül érik el, 
sohasem közvetlenül a tárolókon dolgoznak, hanem azok elemein. A tény, hogy ezek az al- 
goritmusok soha nem közvetlenül vesznek fel elemeket egy tárolóba vagy törölnek eleme- 
ket onnan, leegyszerűsíti annak vizsgálatát, hogy egy kivételnek milyen következményei le- 
hetnek. Ha egy adatszerkezetet csak konstans bejárókon, mutatókon vagy referenciákon 
(például const Rec? keresztül érhetünk el, általában nagyon egyszerűen ellenőrizhetjük, 
hogy a kivételek művelnek-e valamilyen veszélyes dolgot. 


E.5.4. A valarray és a complex 


A számkezelő függvények sem okoznak kifejezetten kivételeket (22. fejeze), de a valarray 
osztálynak memóriát kell foglalnia, így használatakor előfordulhat szd::bad alloc kivétel. 
Ezenkívül a valarray és a complex kaphat olyan elemtípust is (skalárokaD), amely kivétele- 
ket válthat ki. Szokás szerint a szabvány alapbiztosítást (§E.2) nyújt, de a kivételek által meg- 
szakadt számítások eredményéről semmit sem feltételezhetünk. 


A basic string osztályhoz hasonlóan (YE.5.1) a valarray és a complex is feltételezheti, hogy 
a sablonparaméterében megadott típus nem rendelkezik felhasználói másoló műveletek- 
kel, tehát egyszerűen, bájtonként másolható. A standard könyvtár numerikus típusainak 
többsége a sebességre optimalizált, így feltételezi, hogy elemtípusai nem okoznak kivétele- 
ket. 


E.5.5. A C standard könyvtára 


A standard könyvtár kivétel-meghatározás nélküli műveletei az adott C4-4-változattól függő- 
en válthatnak ki kivételeket, a C standard könyvtárának függvényeinél azonban biztosak le- 
hetünk abban, hogy csak akkor okoznak kivételeket, ha a nekik paraméterként átadott el- 
járások kivételt okoznak, hiszen végeredményben ezeket a függvényeket C programok is 
használják és a C-ben nincsenek kivételek. Egy szép megvalósítás a szabványos C függvé- 
nyeket üres kivétel-meghatározással adhatja meg (throwO), ezzel lehetőséget adhat a for- 


dítónak jobb kód előállítására. 


1300 Függelékek és tárgymutató 


Az olyan függvények, mint a gsortO vagy a bsearchO, egy függvényre hivatkozó mutatót 
vesznek át paraméterként, így okozhatnak kivételt, ha paraméterük képes erre. Az alapbiz- 
tosítás (§E.2) ezekre a függvényekre is kiterjed. 


E.6. Javaslatok a könyvtár felhasználói számára 


A standard könyvtár vizsgálatakor a kivételbiztosságra úgy tekinthetünk, mint egy problé- 
mamentesítő eszközre, amely sok mindentől megvéd minket, ha nem okozunk saját ma- 
gunknak kellemetlenségeket. A könyvtár mindaddig helyesen fog működni, amíg a felhasz- 
nálói eljárások teljesítik az alapkövetelményeket (§E.2). A szabványos tárolók műveletei 
által kiváltott kivételek többnyire nem okoznak memória-elszivárgást és a tárolót érvényes 
állapotban hagyják. Tehát a könyvtár használóinak a legfontosabb kérdés a következő: ho- 
gyan határozzuk meg saját típusainkat ahhoz, hogy elkerüljük a kiszámíthatatlan viselke- 
dést és a memória-lyukak keletkezését? 


Az alapszabályok a következők: 


1. Amikor egy objektumot frissítünk, soha ne módosítsuk az eredeti ábrázolást ad- 
dig, amíg az új értéket teljesen létre nem hoztuk és nem biztosítottuk, hogy ki- 
vétel veszélye nélkül le tudjuk cserélni az értéket. Példaképpen nézzük meg 
a vector::oberator—() a safe assignO vagy a vector::bush backO függvény meg- 
valósítását az §E.3 pontban. 
2. Mielőtt kivételt váltunk ki, szabadítsunk fel minden olyan lefoglalt erőforrást, 
amelyet nem kötöttünk (más) objektumhoz. 
2a A , kezdeti értékadás az erőforrás megszerzésével" módszer (§414.4) és 
a nyelv szabályai, melyek szerint a részben létrehozott objektumok olyan 
mértékben törlődnek, amennyire létrejöttek (414.4.1), nagyban elősegítik ezt 
a célt. Példaképpen nézzük meg a leakO függvényt. (YE.2). 

2b Az uninitialized copyO és testvérei automatikus erőforrás-felszabadítást 
tesznek lehetővé, ha egy objektumhalmaz létrehozása nem sikerül (§E.4.4). 

3. Mielőtt kivételt váltunk ki, ellenőrizzük, hogy minden operandus érvényes álla- 
potban van-e, azaz minden objektumot olyan állapotban kell hagynunk, hogy 
az később szabályosan elérhető és törölhető legyen anélkül, hogy nem megha- 
tározható eredményeket kapnánk és a destruktornak kivételt kellene kiváltania. 
Példaképpen a vector értékadását említhetjük (WE.3.2. 
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3a A konstruktorok abban is eltérnek az átlagos eljárásoktól, hogy ha ezekben 
keletkezik kivétel, nem jön létre objektum, amelyet később törölnünk kelle- 
ne. Ebből következik, hogy ha egy konstruktorban kell kivételt kiváltanunk, 
akkor nem kell invariánst helyreállítanunk, de minden erőforrást fel kell sza- 
badítanunk, amit a konstruktor megszakadása előtt lefoglaltunk. 

3b A destruktorok abban különböznek a többi művelettől, hogy ha itt kivétel 
keletkezik, szinte biztosan elrontunk valamilyen invariánst és akár 
a terminate0 függvény azonnali meghívását is előidézhetjük. 


A gyakorlatban ezeket a szabályokat meglepően nehéz betartani. Ennek legfőbb oka az, 
hogy a kivételek gyakran ott következnek be, ahol egyáltalán nem várjuk azokat. Egy jó pél- 
da erre az std::bad alloc. Bármely függvény okozhatja ezt a kivételt, amely közvetve vagy 
közvetlenül használja a new operátort vagy egy allocator objektumot memória lefoglalásá- 
hoz. Bizonyos programokban ezt a hibát elkerülhetjük, ha nem igénylünk a lehetségesnél 
több memóriát, az olyan programok esetében azonban, amelyek elég sokáig futnak vagy je- 
lentős mennyiségű adatot kell feldolgozniuk, fel kell készülnünk a legkülönbözőbb hibákra 
az erőforrás-foglalásokkal kapcsolatban. Ez azt jelenti, hogy feltételeznünk kell, hogy min- 
den függvény képes bármely kivétel kiváltására, amíg mást nem bizonyítottunk rájuk. 


A meglepetések elkerülésének egyik módja az, hogy csak olyan elemekből építünk tároló- 
kat, melyek nem használnak kivételeket (például mutatókból vagy egyszerű, konkrét típu- 
sokbób vagy láncolt tárolókat (például /is9 használunk, melyek erős biztosítást nyújtanak 
(SJE.4). A másik, ellentétes megközelítés, hogy elsősorban az olyan műveletekre számítunk, 
melyek erős biztosítást nyújtanak (például a push backO). Ezek vagy sikeresen befejeződ- 
nek, vagy egyáltalán nincs hatásuk (YE.2), de önmagukban nem elegendőek az erőforrás- 
lyukak elkerülésére és csak rendezetlen, pesszimista hibakezelést és helyreállítást tesznek 
lehetővé. A vectorST"- például típusbiztos, ha a Ttípuson végzett műveletek nem okoznak 
kivételeket, de ha kivétel következik be a vector objektumban és nem gondoskodunk vala- 
hol a mutatott objektumok törléséről, azonnal memória-lyukak keletkeznek. Ebből követ- 
kezik, hogy be kell vezetnünk egy Handle osztályt, amely mindig elvégzi a szükséges fel- 
szabadításokat (425.7), és az egyszerű vectorST? helyett a vectorc HandlexT- : szerkezetet 
kell használnunk. Ez a megoldás az egész programot rugalmasabbá teszi. 


Amikor új programot készítünk, lehetőségünk van arra, hogy átgondoltabb megközelítést 
találjunk és biztosítsuk, hogy erőforrásainkat olyan osztályokkal ábrázoljuk, melyek invari- 
ánsa alapbiztosítást nyújt (VE.2). Egy ilyen rendszerben lehetőség nyílik arra, hogy kivá- 
lasszuk a létfontosságú objektumokat és ezek műveleteihez visszagörgetési módszereket al- 
kalmazzunk (azaz erős biztosítást adhatunk — néhány egyedi feltétel mellett). 


1302 Függelékek és tárgymutató 


A legtöbb program tartalmaz olyan adatszerkezeteket és programrészeket, melyeket a kivé- 
telbiztosságra nem gondolva írtak meg. Ha szükség van rá, ezek a részek egy kivételbiztos 
keretbe ágyazhatók. Az egyik lehetőség, hogy biztosítjuk, hogy kivételek ne következzenek 
be (ez történt a C standard könyvtárával, SE.5.59, a másik megoldás pedig az, hogy felület- 
osztályokat használunk, melyekben a kivételek viselkedése és az erőforrások kezelése pon- 
tosan meghatározható. 


Amikor olyan új típusokat tervezünk, amelyek kivételbiztos környezetben futnak majd, kü- 
lön figyelmet kell szentelnünk azoknak az eljárásoknak, melyeket a standard könyvtár 
használni fog: a konstruktoroknak, a destruktoroknak, az értékadásoknak, összehasonlítá- 
soknak, swap függvényeknek, a predikátumként használt függvényeknek és a bejárókat ke- 
zelő eljárásoknak. Ezt legkönnyebben úgy valósíthatjuk meg, hogy egy jó osztályinvariánst 
határozunk meg, amelyet minden konstruktor könnyedén biztosíthat. Néha úgy kell meg- 
terveznünk az osztályinvariánst, hogy az objektumoknak legyen egy olyan állapota, mely- 
ben egyszerűen törölhetők, ha egy művelet , kellemetlen" helyen ütközik hibába. Ideális 
esetben ez az állapot nem egy mesterségesen megadott érték, amit csak a kivételkezelés mi- 


att kellett bevezetni, hanem az osztály természetéből következő állapot (VE.3.5). 


Amikor kivételbiztossággal foglalkozunk, a fő hangsúlyt az objektumok érvényes állapotai- 
nak (invariánsainak) meghatározására és az erőforrások megfelelő felszabadítására kell he- 
lyeznünk. Ezért nagyon fontos, hogy az erőforrásokat közvetlenül osztályokkal ábrázoljuk. 
A vector. base(§E.3.2) ennek egyszerű példája. Az ilyen erőforrás-osztályok konstruktora ala- 
csonyszintű erőforrásokat foglal le (például egy memóriatartományt a vector. base esetében), 
és invariánsokat állít be (például a mutatókat a megfelelő helyekre állítja a vector. base osz- 
tályban). Ezen osztályok destruktora egyszerűen felszabadítja a lefoglalt erőforrást. A részle- 
ges létrehozás szabályai (414.4.1) és a ,kezdeti értékadás az erőforrás lefoglalásával" mód- 


szer (414.4) alkalmazása lehetővé teszi, hogy az erőforrásokat így kezeljük. 


Egy jól megírt konstruktor minden objektum esetében beállítja a megfelelő invariánst 
(424.3.7.1), tehát a konstruktor olyan értéket ad az objektumnak, amely lehetővé teszi, hogy 
a további műveleteket egyszerűen meg tudjuk írni és sikeresen végre tudjuk hajtani. Ebből 
következik, hogy a konstruktoroknak gyakran kell erőforrást lefoglalniuk. Ha ezt nem tud- 
ják elvégezni, kivételt válthatnak ki, így az objektum létrehozása előtt foglalkozhatunk a je- 
lentkező problémákkal. Ezt a megközelítést a nyelv és a standard könyvtár közvetlenül tá- 
mogatja (GE.3.5). 


Az a követelmény, hogy az erőforrásokat fel kell szabadítanunk és az operandusokat érvé- 
nyes állapotban kell hagynunk a kivétel kiváltása előtt, azt jelenti, hogy a kivételkezelés ter- 
heit megosztjuk a kivételt kiváltó függvény, a hívási láncban levő függvények és a kivételt 
ténylegesen kezelő eljárás között. Egy kivétel kiváltása nem azt a hibakezelési stílust jelen- 
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ti, hogy , hagyjuk az egészet valaki másra". Minden függvénynek, amely kivételt vált ki vagy 
ad tovább, kötelessége felszabadítani azokat az erőforrásokat, melyek hatáskörébe tartoz- 


nak, operandusait pedig megfelelő értékre kell állítania. Ha az eljárások ezt a feladatot nem 
képesek végrehajtani, a kivételkezelő nemigen tehet mást, minthogy megpróbálja , szépen" 
befejezni a program működését. 


E.7. Tanácsok 
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Legyünk tisztában azzal, milyen szintű kivételbiztosságra van szükségünk. YE.2. 
A kivételbiztosságnak egy teljes körű hibatűrési stratégia részének kell lennie. 
SE.2. 

Az alapbiztosítást minden osztályhoz érdemes megvalósítani, azaz az invarián- 
sokat mindig tartsuk meg és az erőforrás-lyukakat mindig kerüljük el. YE.2, 
SE.3.2, SE.4. 

Ahol lehetőség és szükség van rá, valósítsunk meg erős biztosítást, azaz egy 
művelet vagy sikeresen hajtódjon végre, vagy minden operandusát hagyja válto- 
zatlanul. §E.2, SE.3. 

Destruktorokban ne fordulhasson elő kivétel. §E.2, §E.3.2, §E.4. 

Ne váltson ki kivételt egy érvényes sorozatban mozgó bejáró. VE.4.1, SE.4.4. 

A kivételbiztosság foglalja magában az önálló műveletek alapos vizsgálatát. §E.3. 
A sablon osztályokat úgy tervezzük meg, hogy azok , átlátszóak" legyenek a ki- 
vételek számára. §E.3.1. 

Az init0 függvény helyett használjunk konstruktort az erőforrások lefoglalásá- 
hoz. SE.3.5. 

Adjunk meg invariánst minden osztályhoz, hogy ezzel pontosan meghatározzuk 
érvényes állapotaikat. §E.2, SE.6. 

Győződjünk meg róla, hogy objektumaink mindig érvényes állapotba állíthatók 
anélkül, hogy kivételektől kellene tartanunk. §E.3.2, §E.6. 

Az invariánsok mindig legyenek egyszerűek. §E.3.5. 

Kivétel kiváltása előtt minden objektumot állítsunk érvényes állapotba. SE.2, 
SE.6. 

Kerüljük el az erőforrás-lyukakat. §E.2, §E.3.1, SE.6. 

Az erőforrásokat közvetlenül ábrázoljuk. SE.3.2, SE.6. 

Gondoljunk rá, hogy a swapO függvény gyakran használható az elemek máso- 
lása helyett. §E.3.3. 
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Ha lehetőség van rá, a try blokkok használata helyett a műveletek sorrendjének 
jó megválasztásával kezeljük a problémákat. §E.3.4. 

Ne töröljük a , régi" információkat addig, amíg a helyettesítő adatok nem válnak 
biztonságosan elérhetővé. §E.3.3, §E.6. 

Használjuk a , kezdeti értékadás az erőforrás megszerzésével" módszert. SE.3, 
SE.3.2, §E.6. 

Vizsgáljuk meg, hogy asszociatív tárolóinkban az összehasonlító műveletek má- 
solhatók-e. §E.3.3. 

Keressük meg a létfontosságú adatszerkezeteket és ezekhez adjunk meg olyan 
műveleteket, melyek erős biztosítást adnak. §E.6. 


E.8. Gyakorlatok 


. CD Soroljuk fel az összes kivételt, amely előfordulhat az §E.1 pont [0 


függvényében. 


. CD Válaszoljunk az §E.1 pontban, a példa után szereplő kérdésekre. 
. C1 Készítsünk egy 7ester osztályt, amely időnként a legalapvetőbb műveletek- 


ben okoz kivételt, például a másoló konstruktorban. A 7ester osztály segítségé- 
vel próbáljuk ki saját standard könyvtárunk tárolóit. 


. C1 Keressük meg a hibát az §E.3.1 pontban szereplő vector konstruktorának 


rendezetlen változatában és írjunk programot, amely tönkreteszi az osztályt. 
Ajánlás: először írjuk meg a vector destruktorát. 


. (62) Készítsünk egyszerű listát, amely alapbiztosítást nyújt. Állapítsuk meg na- 


gyon pontosan, milyen követelményeket kell a felhasználónak teljesítenie a biz- 
tosítás megvalósításához. 


. 63) Készítsünk egyszerű listát, amely erős biztosítást nyújt. Alaposan ellenőriz- 


zük az osztály működését. Indokoljuk meg, miért tartjuk ezt a megoldást bizton- 
ságosabbnak. 


. 62.Jírjuk újra a §11.12 Siring osztályát úgy, hogy ugyanolyan biztonságos le- 


gyen, mint a szabványos tárolók. 


. G€2) Hasonlítsuk össze a vector osztályban meghatározott értékadás és 


a safe assignO függvény különböző változatait a futási idő szempontjából. 


(SE.3.3) 


. C1.5) Másoljunk le egy memóriafoglalót az értékadó operátor használata nélkül 


(hiszen az oberator- megvalósításához erre van szükségünk az §E.3.3 
pontban). 
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10. C2) Írjunk a vector osztályhoz alapbiztosítással egy egyelemű és egy többelemű 
erase0), illetve insertŐ függvényt. §E.3.2. 

11. (2) Írjunk a vector osztályhoz erős biztosítással egy egyelemű és egy többelemű 
erase0), illetve insertŐ függvényt (YE.3.2). Hasonlítsuk össze ezen függvények 
költségét és bonyolultságát az előző feladatban szereplő függvényekével. 

12. G2) Készítsünk egy safe insertŐ függvényt (V4E.4.2), amely egy létező vector ob- 
jektumba szúr be elemet (nem pedig egy ideiglenes változót másol le). Milyen 
kikötéseket kell tennünk a műveletekre? 

13. C2.5) Hasonlítsuk össze méret, bonyolultság és hatékonyság szempontjából 
a 12. és a 13. feladatban szereplő safe insertŐ függvényt az §E.4.2 pontban be- 
mutatott safe insertO függvénnyel. 

14. (2.5) Írjunk egy jobb (gyorsabb és egyszerűbb) safe insertO függvényt, kifeje- 
Zetten asszociatív tárolókhoz. Használjuk a traits eljárást egy olyan safe insertŐ 
megvalósításához, amely automatikusan kiválasztja az adott tárolóhoz optimális 
megvalósítást. Ajánlás: §19.2.3. 

15. 2.5) Próbáljuk megírni az uninitialized fill0 függvényt (419.4.4, SE.3.1) úgy, 
hogy az megfelelően kezelje a kivételeket kiváltó destruktorokat is. Lehetséges 
ez? Ha igen, milyen áron? Ha nem, miért nem? 

16. (2.5) Keressünk egy tárolót egy olyan könyvtárban, amely nem tartozik a szab- 
ványhoz. Nézzük át dokumentációját és állapítsuk meg, milyen kivételbiztossági 
lehetőségek állnak rendelkezésünkre. Végezzünk néhány tesztet, hogy megálla- 
pítsuk, mennyire rugalmas a tároló a memóriafoglalásból vagy a felhasználó által 
megadott programrészekből származó kivételekkel szemben. Hasonlítsuk össze 
a tapasztaltakat a standard könyvtár megfelelő tárolójának szolgáltatásaival. 

17.€3) Próbáljuk optimalizálni az §E.3 pontban szereplő vector osztályt a kivételek 
lehetőségének figyelmen kívül hagyásával. Például töröljünk minden try blok- 
kot. Hasonlítsuk össze az így kapott változat hatékonyságát a standard könyvtár 
vector osztályának hatékonyságával. Hasonlítsuk össze a két változatot méret és 
bonyolultság szempontjából is. 

18.C1 Adjunk meg invariánst a vector osztály (YE.3) számára úgy, hogy megenged- 
jük, illetve megtiltjuk a v-—0 esetet (VE.3.59. 

19. €2.5) Nézzük végig egy vector osztály megvalósításának forráskódját. Milyen 
biztosítás áll rendelkezésünkre az értékadásban, a többelemű insertO utasítás- 
ban és a resize0 függvényben? 

20. (3) Írjuk meg a hash map (§17.6) olyan változatát, amely ugyanolyan biztonsá- 
gos, mint a szabványos tárolók. 


